Plenty of people claim that they're scared to contribute because Linus might yell at them. That's unfounded for a lot of reasons.
TL;DR: Test your code before you submit it. Don't accept or acknowledge patches from others that haven't been reviewed or tested. And if you make a mistake, own up quick and he's not going to yell at you. It's pretty simple.
He will occasionally jump in and yell when people aren't accepting responsibility for problems they caused. Especially when they won't accept nicer, less authoritative criticism from their peers.
That's what happened in this case. Check the follow-up message in the thread where Linus explains his dissatisfaction (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02507.html). The contributor who caused the regression was caught denying that there was even a regression. His patch had already long been identified as the culprit and reverted. But over the course of three weeks he was insisting that it was not a kernel regression. Essentially he dug in for 22 days saying that it wasn't his problem. And he wasted tons of valuable contributor time where people were nicely telling him that, yes, it was indeed a regression.
Multiple people were telling him about the "don't break userspace" policy and how it was a regression. And yet that contributor was still deflecting responsibility for the problems caused. But the problem is that this patch would leave the distros in the lurch - scrambling to update their configuration before the kernel breaks behavior. And that's without any ETA on their "long term ... flexible solution" (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/00380.html). Thousands of people with varying levels of technical competency would have had their systems break in unexpected ways.
Quite frankly, he earned the dressing down. And plenty of people tried to be nice to him about it. It just didn't take hold in his mind until Linus dropped in to rudely remind him that even "correct" behavior is a regression if it breaks userspace. Also note that Linus said the issue had been escalated to him. Someone explicitly brought this to his attention because there was a distinct lack of progress due to CYA responsibility deflection.
> It's not a regression unless something was broken first, then fixed, then the SAME ISSUE comes back in a later code change.
No, it's when a change results in unintentional behavior that breaks previously supported scenarios. You might want to double-check your definition. I think you're actually referring to a recurring issue.
It might not be about commercializing so much as including it in some of the *BSDs which don't allow for GPL code in the core. Otherwise, they'll probably have to write a new implementation. But yes, there is that risk.
First of all, love the project. Thanks for tackling it and sticking to it.
I know that talking about a windows client is really early at this point, but is your team considering implementing it in a way that actually uses the UWP VPN provider interfaces (https://docs.microsoft.com/en-us/uwp/api/Windows.Networking....) instead of (or in addition to) the OpenVPN-style system tray app? I know there's been some strides towards using UWP from rust. And if you're thinking about it, early consideration might give extra time for any necessary interactions with MS.
It would be really nice to have an open-source VPN implementation actually integrate with the OS, and I think it might provide the impetus people need to ditch OpenVPN. So even if you don't plan on directly working to integrate with the OS interfaces, please consider referencing the APIs when working on userspace libraries. Keeping the needs in mind could at least simplify any future efforts in that regard.
The OpenVPN Windows kernel TUN/TAP driver is really super scary. That alone has a larger code base than all of WireGuard...
At the moment, the efforts around the cross-platform userspace-based WireGuard implementations have focused on targeting that TUN/TAP driver, which is pretty ugly business. But thanks very much for pointing me toward this more general purpose API.
It might wind up being _easier_ to use this than having to talk to terrible OpenVPN kernel drivers. I'll investigate this thoroughly.
By the way, if you're into Windows programming and want to help out, don't hesitate to email team@wireguard.com.
> The OpenVPN Windows kernel TUN/TAP driver is really super scary.
I believe you. Everything about OpenVPN code scares me. Not sure if it helps, but I checked out an article by Dmitri Varsanofiev on using the TUN/TAP driver (http://www.varsanofiev.com/inside/using_tuntap_under_windows...) and it seems he was able to work with the driver from managed (C#) code without actually modifying the driver source at all. It seems he was just invoking two Win32 API call methods from Kernel32.dll: CreateFile and DeviceIoControl. If he can do it from C#, it should be doable from rust.
From his sample, it seems you could work with the tunnel device without modifying the source code at all. Although that means you've still got a major code wart from OpenVPN haunting you. And even if it works, I'm not sure if that's the recommended approach. But if you're insistent on supporting Wireguard on Windows versions before 10, the TUN/TAP driver might be the only route available. I don't think those VPN APIs existed in Windows 7 and I think they were private in 8/8.1, if memory serves.
The good news about the UWP APIs is that you once you confirm that it works, you could potentially get it up on the Windows store and make it easy for people to install and update. Though there's tons of notes that the VPN APIs are restricted, and you can only publish apps that use them after you get reviewed and your account gets those permissions. You can still sideload, (locally install) though. Honestly, I don't think the review would be a huge obstacle, though. I think Wireguard has some fans in MS.
> By the way, if you're into Windows programming and want to help out, don't hesitate to email team@wireguard.com.
I mostly work on the managed side of things, but I try to keep fresh on APIs and platform features. I'm not sure my workload really allows me to be a major part of the project, but if you've got a public portal that tracks your tasks, I might be able to subscribe and pop in and do some legwork from time to time. Especially if someone's writing the core functionality in some DLL that's easy to call. Do you have a public issue tracker? Or is it mostly IRC and mailing lists?
> he was able to work with the driver from managed (C#) code without actually modifying the driver source at all
Yea, I wouldn't need to (or want to) modify the source, and using the actual driver from userspace isn't that bad. Also, having a pre-signed win32k driver is a nice thing that I wouldn't want to give up. My motivation is mainly to avoid using it all together, if possible, which is I think what the API you linked to prior will allow.
So the UWP API looks like the right way forward. I wonder if we could launch it as Win 10+ without too many complaints. Nobody is really using 8/8.1, but there are of course corporate Win7 holdouts.
> Do you have a public issue tracker? Or is it mostly IRC and mailing lists?
There's wireguard.com/todo/ but it hasn't been populated with the particular TODOs for the userspace stuff. But if you send me an email or come into the IRC, I can fill you in at the optimal time when it seems like _the one thing remaining_ is just to fill in some platform-specific stubs for win32. If that's appealing to you, of course.
> There's also a warning the first time you use it
If you'd actually read the issue before commenting, you'd realize that this behavior was added after people complained about the telemetry not being obvious. It's the sixth comment on the issue (by guardrex) - not even that far down. The very next comment is an MS contributor saying that he makes a good point that it wasn't obvious, and that they'd improve it in a future release. Which is why there's now a warning when using it. I mean, the link is old, but it should be understood that an issue on preview tooling from over a year ago might not represent the current state of the tooling. But yeah, on first release, all the notice you got was a blog post, if you even bothered to look for it.
It's also a fair point that it's still not made very clear that what information is collected under what circumstances. It's a huge problem with Windows, so you can understand why people have their jimmies rustled even over something small. Especially since windows 10 makes it impossible to completely opt-out of telemetry. Even after disabling the visual options, it's still regularly calling out to Microsoft servers. Even if you disable the services, updates will turn them back on and other services will start it up. And then it chews through your system's CPU like it's starving. Which means it's probably collecting far more data than it needs.
Finally, sometimes it's not even about what's collected or that there's an opt-out procedure. Sometimes just having a mechanism for transferring data can cause problems. 'sushihangover' comments on that issue that someone failed their HIPAA audit based on this behavior. I've no idea if it's an accurate example, but there are government, medical and enterprise environments where any non-sanctioned traffic is strictly prohibited and can cause liabilities.
Telemetry needs to be easy, simple, and thorough in its opt-out mechanisms. Microsoft has failed its users on this frequently and recently. I don't think this particular instance is that bad, but they should be doing damage control in all products based on the public perception that they're spying on users.
SQL Server Management Studio, on the other hand, is much better about its analytics opt-in request. Microsoft is a big company with varied practices. Not every division deserves a high-five about their privacy practices.
> It's definitely nothing out of the ordinary and is common practice among many tools and apps you already use. Your smartphone sends back way more data if you're that concerned.
Let MS take their knocks when they earn them. And it's totally fine if people point out that Microsoft has a problem with opting users into unwanted telemetry. Even if it's not important data, it's data that someone didn't volunteer to give up. It's a horrible, common-place practice that needs to end.
Honestly, they might not need automatic telemetry if they just made volunteering information during a bug or slowdown significantly easier. If it was easy to, for example, enable telemetry for a Visual Studio session to track down why it runs like a whale, and then to review the information sent before it was sent, people would use it all the time to better the software. Instead, people turn off everything they can and don't bother to enable it (required for some MS feedback apps) to report issues because they don't know what'll sneak across.
When your telemetry is easy, open, and transparent, people will gladly opt-in when they think it's needed. Or they can hide the data they care about and share the rest.
> When your telemetry is easy, open, and transparent, people will gladly opt-in when they think it's needed.
Well said. As a favour to the developers, I have always chosen to opt in for telemetry when it was asked upfront and in a transparent and guileless manner. One example is Firefox, where I opt in for its telemetry.
What I suspect I (and others) don't like is software that treats the user as if they're too dumb to decide for themselves and somehow too inconsequential to have full control over the software that they have bought. It gives off the impression that the software is more important than the user or their work/machine, which is why we see such a backlash. Stallman is right in this sense. You don't need to open source your software, but make the user your priority. Treat them well. And watch your software be praised far and wide. Conversely....
they don't just want to get a lot of data, they want representative data. they're afraid that, even if many/most people opt in, if the sort of person who opts in is different from the sort of person who doesn't, and has different usage patterns, the data will be skewed.
I think one of the issues is the maintainer of an open source project will always have the final say in which patches are accepted. So the best way to not have any telemetry would be to fork the project and remove the offending code. Also historically, is /var/log any different from telemetry? I can easily figure out which applications were installed, what the hardware on the system is, which cron jobs were executed etc.
But in any case I agree that MS should definitely allow the owner of the machine the ability to block the transmission of any and all telemetry data.
Yeah, it's possible. And it will probably happen at some point or another, now that it's open source. But that won't stop the momentum of the core product.
> Also historically, is /var/log any different from telemetry? I can easily figure out which applications were installed, what the hardware on the system is, which cron jobs were executed etc.
Telemetry by definition includes the transmission of logged data. System logs may be collected and transmitted internally by an organization, though by default it is not. But pretty much everyone would be up in arms if a software vendor collected logs of not only what their own software is doing, but what other software on a user's system is doing. And that's the main problem with Windows telemetry - it's too invasive, resource intensive, opaque, and integrated for people to stomach. So they turn it off wherever they can, and thus starts this disgusting game of whack-a-mole with Microsoft.
The dotnet cli isn't as bad, but Microsoft has earned some black eyes from the behavior of their other departments. So everyone's going to feel the heat until they learn too control their greed for data.
Yeah, you're correct.. telemetry does include the transmission.
>And that's the main problem with Windows telemetry - it's too invasive, resource intensive, opaque, and integrated for people to stomach. So they turn it off wherever they can, and thus starts this disgusting game of whack-a-mole with Microsoft.
Ironically, its mainly the technical users who fiddle with all the knobs the OS provides anyway. The same technical users who write tech blogs, influence IT decisions, etc etc. Not having those knobs exposed for telemetry was a bad business decision on MSs part. I've managed to block it at the IP level when I installed W10, but I definitely don't want to be micro managing that.
If crimes were easily trackable and prosecutable, we probably wouldn't have such a hard time keeping criminals in jail. We still have crimes committed in jail that don't get properly solved, much less sentenced.
Also, this isn't necessarily about dumb kids being busted for drugs or stealing, but organized crime members. The possibility of them ordering hits from inside prison walls or tracking down people in witness protection kind of makes people nervous about letting them talk with anyone and everyone. That's not to say it's the most effective means, since smuggling, messengers, visitors and other means still exist for passing information. But that's not really an excuse to not try at all.
I'm pretty sure that the vast majority of prisoners are not mafia bosses who order hits from prison. I'd consider it totally okay to isolate these people.
But most prisons are filled with dumb kids busted for drugs or stealing, and I see no reason why we should make them even more miserable... I'd rather have them keep their connections in the outside world, so they have more of a chance to get back on their feet once they are released.
(Also, I'm pretty sure an prisoner browsing Facebook all day makes a lot less trouble than one who has nothing to do all day...)
Prisoners already have communication mediums that guards can monitor and if they want to talk to someone with no prying ears or eyes, they can talk to a lawyer. Prisoners should have no need for cell phones or access to unrestricted communications. Yes, there are some young people in prison that really shouldn't be but there are plenty of dangerous gang members in there that should be totally removed from their "business responsibilities".
> academics provide such an incredible amount to the world we live in.
This is true, but it's not terribly efficient about doing so. Much of it provides little to no useful return, and some of it actively harms the world we live in. If we wish to talk about the value of academics, we must honestly look at the whole balance sheet. Value isn't just about revenue, but costs, as well. And with rising tuitions and falling class quality, the ROI of a college education isn't as high as it used to be. For students and for society in general.
> the academic discipline with its rigor, criticalness, and policing against self-promotion is a kind of last-bastion for intellect in the West.
I'm really struggling to word this in a polite way without discarding facts (sorry if I'm rude), but, what kind of fantasy led you to believe this is or has been the standard for academia?
- Academic discipline is more about knowing how to file papers and abuse TAs and post-grad students for free work, rather than about following scientific processes. There's been truckloads of articles lately about insufficient scientific rigor on published papers - especially in the social sciences. The glut of students, professors and information has lead to more noise than signal. Self-referential theories get presented as fact, where papers reference other papers still in peer review. Student thesis subjects are encouraged to focus on the professors' work in order to increase citations and prestige. Controversial papers are encouraged instead of scientific papers, which has caused all sorts of problems in academic journals and the parasitic journalists who write clickbait from them. And then there's the ever-present massaging of data and discarding of any contradictory samples.
- Self-promotion is absolutely huge in academia and has been that way for decades. That's how "publish or perish" came to be a staple of the industry. Not to mention the prestige factor in selecting mentors and advisors, politics in academia between people at the professor level can get extremely vicious. Elite oligarchies are as fixed in academia as anywhere else. And if they can't teach, they just move into administration and promote themselves there. Administration is probably the worst part of a modern educational institution - full of waste and corruption. Like how Katehi got rehired at her chancellor-level salary after a year's vacation after that pepper spray incident at UC Davis. Academia is literally infested with bad actors. Not to say there aren't good ones, but the bad ones are especially well connected and hard to evict. There's no policing against it except against the people who get caught before they're successful at entrenching themselves.
- Critical thinking isn't even remotely a curriculum requirement anymore. Many classes actively discourage critical thinking, and instead encourage rote memorization or directed analysis instead. In some classes, if you dare to challenge the narrative presented, you might receive Title IX sanctions for your oppressive actions from students and professor. After which you'll then be brought before a panel, denied representation and judged by a biased group more focused on maintaining image and federal funding than on the truth. And this might be from something as small as questioning the statistics or the sample set from a study. Students are encouraged with safe spaces and other policies that prevent them from processing or even seeing opposing viewpoints. That is not "criticalness". It's pandering.
- Deceiving students in academia is also a thing. Once again, there's the whole problem with scientifically bad papers being encouraged, published and referenced without peer review. These things make it in to curriculum and don't get pulled out after a retraction. Some classes will teach you that you shouldn't critique at all. Class books are often written by the professor to supplement their income, and contain their own pet theories. They put out a new edition every year with minor changes just so you can't buy a used book. And you've obviously never sat through a lecture rant on the professor's pet grievances. Lecture after lecture on the evils of western civilization from a person who literally couldn't survive outside of it can really tire you out. And honesty about career applicability for degrees is at an all-time low. Partly because some of the people teaching you have limited career aspects themselves and don't like to stare the facts in the face. Dishonesty about the value of the information presented and its critical reception is kind of the worst kind of dishonesty when you're charging someone a year's salary to listen to it.
There are good things about a university education. And not every situation is this bad. But it is not the ivory tower you're perceiving, and likely hasn't been that way for the majority of your lifetime, if not all of it. The honest, naked pursuit of science and truth always been the ideal, but rarely the reality. We don't want to throw the baby out with the bath water. But we've got to be more honest and objective about problems in academia if we have any hope of fixing them.
@justabystander wow your reply was long and very detailed and you put a lot of effort into it.
Let me add one more point, and see if what I said merges with what you said. If not I'm completely wrong.
A lot of books, like The Idea Industry by Daniel Drezner and also Science-Mart by Philip Mirowski say that the cutting of university budgets since the late 60's has led to such an undermining of their stability that Academics have had to engage in a stupid, pointless, survival battle of numbers, conformity, and politics. I'm sure the politics was there beforehand, but they make a convincing case that critical thinking and independent research is much more possible when you're not afraid of losing your funding all the time / scared in general about your job.
An additional point to this is that a lot of individuals see the cutting in college funding as the GOP's revenge for the 1960's, because a lot of the behavior of that era was seen as coming from college campuses. UCLA was actually free up until 1967 when Governor Ronald Reagan began the process of charging tuition.
So in conclusion, academia does have a lot of terrible things about it, but I think say 60% of it is fixable simply with a better relationship and funding style between universities and the government.
There's also Google's terrible reputation of poor and unreachable support, as well as the unappealable terminations of service. And they're not limited to consumers - some companies have had service terminated leaving them with no recourse.
Google's offerings are as much software as hardware, and having Google drop your account over a misunderstanding and thereby disabling all your laptops for several weeks would be a nightmare. Many of the people in charge of making purchasing decisions will have this type of concern in mind.
Whether they can turn that around and make a strong enterprise support channel is a valid question. But it's going to take some strong sales and tech to get people to risk trying it out. Google's a great company as long as you don't have to actually talk to anyone. Which makes them wholly undesirable for companies that obsess over the number of nines in their reliability.
In another lifetime, we bought a Google Search appliance. It never did work as well as they said it did. The support was pretty good, for the first month. After that, it got more sparse and less helpful. Reaching someone on the phone was not easy. We weren't the only people to notice this and complain.
It's just an anecdote, so weigh it appropriately. I've absolutely no idea if they have improved.
Just to add a counterpoint to this experience report, I use GCP and pay for their support, and have found it to be generally great (with some variability in quality of SE).
I understand that this isn't the experience that folk have with every Google product, but I suspect that any enterprise support would hook into their GCP support platform.
Concerns about "turning off your account" are certainly valid, though you that's something that Amazon or any other SaaS vendor could do with (I've seen a few nightmare reports over the years, though they seem to be the exception not the rule).
There is a big difference between supporting cloud services and hardware deployed at a customer end point. Google has a history of providing mediocre at best support for the latter.
> There's also Google's terrible reputation of poor and unreachable support, as well as the unappealable terminations of service... some companies have had service terminated leaving them with no recourse. Google's offerings are as much software as hardware, and having Google drop your account...
That's directly referring to cloud services/software support, not hardware support; I'm not making any claim about the latter.
> having Google drop your account over a misunderstanding and thereby disabling all your laptops for several weeks would be a nightmare.
This I think will be the biggest challenge. I've never heard of Microsoft disabling software or cancelling support if by some stroke you were audited and failed. The matter is handled outside of normal business operation.
We're in Germany, and have tried for 4 months to get my sister's Nexus 5X repaire d or replaced. The damage was caused by a third party, who is willing to pay for repair or replace.
So far, so simple.
It's been 4 months of calls, emails, faxes, and sending the device back and forth between Google, LG, the insurance, and the repair facility.
Google says they're not responsible for Nexus devices, so we should talk to LG. LG says they're not responsible, we should talk to Google. We got someone at LG to discuss this, and they told us to send it to their official repair facility. They just sent it back because of a typo on the form, or because the insurance didn't say fast enough that they'd fund it, or because "dunno".
We've now taken the device to Media Markt to get it repaired, and it took 2 days.
Never ever are we going to buy a device from Google again.
Odd, it took me a single phone call to get my 5X replaced when it started bootlooping. I called Google, and they replaced it well out of warranty after a 20 minute phonecall.
(disclosure I work at google but this was before I started)
That may be fine if you get a warranty replacement, but even if you want to pay, getting a repair is basically horror.
This is now the second time we’ve had this odyssey with Google (the Nexus 7 2012 being the first case), and by now it’s obvious it’s not a problem with the OEM, but Google.
Google are reasonably responsive on hardware issues, the problem is software ones. Google have significant issues closing or limiting accounts with no support or recourse to find out what the problems are and resolve them (if they're even real). Given the reliance ChromeOS has on Google accounts that's a huge problem. Eminently fixable from Google's end, but a problem today.
5. Many authors on the papers don't want to share the data from their papers - even if it's a condition of publication. (from a previous article about the GRIM test that I can't find) This doesn't directly equate to maliciousness or deceit, but it illustrates incorrect attitudes in the field. Some authors consider it undignified to have someone "check their work". Others are concerned of fallout if their data contains errors. (Generic mainstream blog/press article on reproducibility https://www.vox.com/2016/3/14/11219446/psychology-replicatio...)
6. Ridiculously small sample sizes are often used in experiments. Often this doesn't seem to affect how the results are received, though it should. (briefly discussed in article and comments)
7. Papers and studies are cited in articles and future papers before they've been peer reviewed, replicated, or proven sufficiently to justify their inclusion into the field. Thus the results are "baked in" to social psychology as fact at an uncomfortably early stage. (http://blogs.plos.org/mindthebrain/2015/12/30/should-have-se...) This kind of feeds into the hype machine where people focus on significant results - even if the data needs massaging to get there. Even after being refuted (if refuted) the field and its fans never seem to fully recover and back away from bad science. By then it's already made its rounds on Facebook and it's even referenced in the worst of the college intro to psych/sociology courses.
8. Journals in general need to be more open with their data. Especially with publicly-funded research. Paywalls don't help progress.
9. Corporate/politically funded white papers publish studies without making the connections clear.
The field needs a massive overhaul in the sense that its participants need to stop chasing controversial results in the press and instead focus on reproducible results and methods. All fields need some of this, but psychology needs it more than others.
Isn't the risk that your negative results harbour a poor experimental methodology, a deficiency in technique or what have you.
That's a pretty big reason not to publish a negative result, especially if the original result has social credence (big name, popular publication, wide acceptance).
Are negative results more likely to have methodological or experimental error than positive results? I've never heard that claim.
I would actually expect the opposite, as finding evidence to support a new claim should be more difficult than not finding evidence.
My understanding is that a negative result has the following format: "we did such and such experiment and did not find a significant statistical relationship between thing 1 and thing 2, after controlling for a bunch of other things".
It's worth noting that this by no means proves that there isn't a relationship, it just means that study wasn't able to find evidence of one. It could be a piece of the puzzle for a potential strong case against such a relationship, or that further research is needed to untangle any confounding factors. Which is why I think all methodologically sounds results should be published, no matter how unflashy or boring.
> UDF supported by all three OSes natively and openly
Wasn't there a major problem in that all the operating systems supported different versions of the UDF standard? And most of them treat it as an optical disk format, so I wouldn't be surprised if some of them acted like it was read-only.
TL;DR: Test your code before you submit it. Don't accept or acknowledge patches from others that haven't been reviewed or tested. And if you make a mistake, own up quick and he's not going to yell at you. It's pretty simple.
He will occasionally jump in and yell when people aren't accepting responsibility for problems they caused. Especially when they won't accept nicer, less authoritative criticism from their peers.
That's what happened in this case. Check the follow-up message in the thread where Linus explains his dissatisfaction (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02507.html). The contributor who caused the regression was caught denying that there was even a regression. His patch had already long been identified as the culprit and reverted. But over the course of three weeks he was insisting that it was not a kernel regression. Essentially he dug in for 22 days saying that it wasn't his problem. And he wasted tons of valuable contributor time where people were nicely telling him that, yes, it was indeed a regression.
Multiple people were telling him about the "don't break userspace" policy and how it was a regression. And yet that contributor was still deflecting responsibility for the problems caused. But the problem is that this patch would leave the distros in the lurch - scrambling to update their configuration before the kernel breaks behavior. And that's without any ETA on their "long term ... flexible solution" (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/00380.html). Thousands of people with varying levels of technical competency would have had their systems break in unexpected ways.
Quite frankly, he earned the dressing down. And plenty of people tried to be nice to him about it. It just didn't take hold in his mind until Linus dropped in to rudely remind him that even "correct" behavior is a regression if it breaks userspace. Also note that Linus said the issue had been escalated to him. Someone explicitly brought this to his attention because there was a distinct lack of progress due to CYA responsibility deflection.