jake_the_third

Tell that to my father who still uses decades-old software. I agree with the gp, Windows Home users need this feature the most.

Folks who don't mind Windows S would already be using android/ios.

Thank you! Although this information is out their, compiling the people involved into a list like this makes for much easier research.

> The only user-hostile behavior I mostly agree with his forced, frequent updates.

.. by default.

An owner should always have the final say in what his machine does. If they choose to disable automatic updates, then that's their prerogative and they bear the consequences.

I am having a very hard time believing this statement is in any way true. If you have a link to details, now is the time to provide it.

>166

Yikes!

Does anyone know where I can get an overview of the entirety of rocket's dependency graph. Crates.io only lists 11 direct dependencies.

> I get about 2 wrong every time on purpose.

I do the same, but actually get google to accept bad data as good. The trick is to get the system to trust you (e.g. by supplying one honest answer), then selecting answers that the system is likely to be unsure about. If done correctly, you can get them to accept a lot of bad input this way.

Like you, I am under no illusion that this will have some sort of effect on the correctness of the resulting ML models, but I like to think that I am at least delaying or otherwise decreasing the training rate.

Have google adopted stackoverflow's model of making the result of our unpayed work available to us, I would have answered these challenges honestly.

I don't think it's defending chinese companies as much as it is highlighting that companies on both sides are susceptible to more or less the same type of government control.

I personally think it's something worth mentioning when it's the most common reason cited for avoiding a chinese company.

Then again, at the end of the day, you have companies with strong links to an adversarial government and which has been proven to have conducted economic espionage for the benefit of domestic companies, regularly violated (and violates) human rights, overthrown elected governments, invaded countries under false pretenses, and sentence people to death without a fair trial. If that's your line of logic, then there's more than enough shit to go around. Both sides are shitty.

The point being made is that industry-level security is not real evidence of malicious behavior on huawei's part. If you want people to avoid huawei, present proof.

All I and others are asking for is some hard evidence. Either the company is engaged in unsavory behavior or it is not. You can't be ambiguous about this and expect people to play along.

Given how easy it should be for a capable government like the US to find something like this (especially given how common huawei gear is) and how "friendly" the US has been with China, I would expect to have seen at least some evidence surface by now. In fact, I would take the lack of evidence as a testimony to the innocence of huawei and the security of their hardware.

I fail to see how this ties into your original point.

From where I'm sitting, both are not transparent and accountable.

Then we shouldn't deal with Cisco, Juniper, and pretty much every other network equipment manufacturer.

What kind of logic is that?

> is there any hard evidence that huawei is a legitimate security concern?

As someone with a lot of huawei in their infrastructure, this is what I really want to know as well.

The US government has lost a lot of credibility over the last few decades with its lopsided foreign policies that completely tip towards self-serving and agenda-pushing rather than decency and public good. There is nothing indicating that this particular issue is any different.

Unless the US government shows hard evidence that the company is harming us, we're not ditching them.

Innocent until proven guilty applies to entities you don't like too.

What is JAB's patent situation like? One of QR-codes most important attributes (for us, at least) is that patent threats are relatively low.

Has research been done to see how safe implementations are from infringing on currently-valid patents?

I've just skimmed over the both specifications and haven't noticed anything that would indicate that this is a "weekend project". In fact, I'm impressed enough that I might work on an implementation in my preferred language (assuming a decent testing dataset is available).

What exactly are the technical issues that make you dismiss this project so harshly?

Depending on LD_PRELOAD is extremely fragile and finicky.

Not only can a process sidestep libc entirely by calling the `open`(2) syscall, but there are often many ways of combining function calls to achieve the same outcome. This method will also fail completely on systems that have new, previously unknown functions that are not monitored by the LD_PRELOAD solution.

Worst of all, a LD_PRELOAD solution would not cover operations that are done on the behalf of the target program by external programs via IPC (think system daemons and dbus), at least not without intercepting and interpreting all io that target does.

In short, it doesn't scale.

Seeing that there was a vulnerability in python just a couple days ago, I'd consider getting security updates a benefit.

Most people will stop running python 2 when malware targeting it becomes rampant. So people being able to run your code is another benefit.

:o)

Unless they allow the same kind of control a user can get with normal x86 machines or better, I can't see this being taken seriously by developers. I can't see developers jumping on a closed, locked-down platform other than apple's (and even those folks are starting to get tired).

> Devs tend to install upstream tools instead of the out of date RHEL tools too.

and system administrators tend to install packaged tools instead of upstream tools that aren't tested to play well with the rest of the system.

Perhaps installing directly from upstream makes sense for Go, but the servers I maintain either run distro-packed software or custom software.

Too many bad experiences with upstream packages to trust on production.

I agree that my claim was unsubstantiated and redact it.

What I was trying to convey is that I would expect people who don't understand or care enough about their personal privacy would use more popular and mainstream messengers. Whether people who care about privacy consider phone numbers private or not is something we need data to determine.

> Where's your survey data that says Signal users just can't stand the phone-number-as-id thing?

That's exactly what I'm asking for. At this point, we're both speculating. None of us can make solid claims about either userbase without providing evidence. tptacek most certainly can't claim " a small but vocal minority of Signal's user base wants non-phone-number identification" without providing evidence either, which is the original objection that started this thread.

Don't expect people to take your reason for dismissing their concerns seriously when you base it on your personal perception or beliefs in stead of facts, and don't make unsubstantiated claims to discredit their concerns.

Those users do not use it a secure messaging platform. The see it as a way to get around SMS fees. The majority of Signal users are likely privacy- and security-focused, and chose to use signal because of the features it provides on those fronts.

Comparing those two userbases doesn't make much sense to me.

Then if we take this 0.2% as representative (and 6 million out of three billion users probably is), it would be fair to say that this 50% split would scale if more people learned about javascript.

Google will be in hot water if humanity ever decides to take on javascript.. assuming the source for those states aren't someone's ass.

I don't see how. Could you explain?

I was under the impression that the wasm emscripten target was deprecated in favor of the rust-specific wasm target. Am I wrong?

Yes. More precisely, I stopped when I discovered that I couldn't decouple the signal user from my phone number.

More importantly, I'm still very interested in seeing the data behind your vocal-minority assertion.

> A small but vocal minority of Signal's user base wants non-phone-number identification.

Have you done a survey before arriving to this conclusion. If so, I'd love to take a look at it, if possible. Otherwise, I can't see how you can make this assertion; everything can be dismissed as a "small but vocal minority".

As a previous signal user, I stopped using signal because I discovered this issue.

Is there documentation on Rust+WebAssembly that is presented more like a conventional book or tutorial?

I don't do well with example-driven documentation like these. Resources like the original rust book are excellent though.

And the BSDs have mostly moved passed the era of legal ambiguity that plagued them early in their development. For better or worse, timing and initial impressions count.

Now for the benefits:

* Better feature stability, * Robust and well-defined standards, * improved security, * better debugging options, * and most importantly competitive pressure.

Just look at how LLVM pressured GCC into shape. I'm primarily a GCC user, but I'm very very grateful for LLVM's existence. Also multiple equally competent compilers disincentivise them from going rouge (e.g. .net telemetry).

Weighing the pros against the cons, I'd have to stand with GP in saying that choice is good.

The critical faults with D that prevented it from displacing C* were that it relied on a GC by default and that it wasn't open source. Things might have played out much differently had they addressed these issues early on.

* aside from inertia, but older languages also had inertia once.