sambe

The question the court is asking is "why can't the drivers?". Uber is claiming to be a third party here.

The way you have quoted this suggests it is being said by the author, whom you are disagreeing with. It's not: it's being said by someone else (in an issue filed against the repo), and the author also mostly disagrees.

I guess you are also supposed to figure out for yourself what private information of yours has been compromised, since they can't be bothered to make it explicit.

Where was it submitted? I couldn't see that anywhere.

I also use Telegram because one of my friends was really stubborn. Like many here, I think it's a great service/client but probably has some security issues (although they are largely trade-offs). However, I don't agree that my example backs your view: there's no way I could get my other friends and family to switch en-masse. I still only use it pretty much with that one friend and a small group around him. And all the others say the same: they hate on the guy for being a pain despite liking the app.

Yes; that's my latter point - it could easily have been a bad technical choice. But that doesn't really validate the "big mess"-style criticism, which I have mostly found to be untrue.

I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.

I recently had an SSD failure and tried using Ubuntu 20.10 to fix my (heavily tweaked to get things mostly-working) older Ubuntu installation. After many hours fiddling with startup settings I still cannot get the live USB to boot to anything other than a black screen. This is a ~2008 graphics card with mature open source drivers. I can get a console if using safe graphics mode but then no network connectivity either. Who knows about sound, haven't got there yet. All the same issues as 15-20 years ago.

When I was last using this machine regularly, most biannual upgrades broke one of these three things anyway (and, no: the tweaks were not obscure things that caused the breakage, and several failed attempts were made to revert them, report them, or look into the causes, and they obviously don't affect the live USB).

That and taking 5 minutes to figure out that it can't possibly do what you told it to (except, of course, it can).

I would far rather we report with just the tiniest bit of nuance. They did distinct variations for a reason. Nobody is reporting all the other approaches that were less favourable.

"Can be" or "will be"?

The cables die all the time! (depending on how much exposed innards you are comfortable with). They last longer when other family members are not using them but even my exclusive, careful use of one that only sits by my bed has pulled itself apart.

The article is a bit of a strawman but I think it's inexcusable to be charging nearly twice the price of the charger for a 2m cable that disintegrates after a year or two. Especially when - as you say - they've changed the one in the box backwards-incompatibly (and it's 1m too).

Ok, I'll ask the obvious question: why did setting the branches option to master not already do this?

EDIT

https://www.jenkins.io/doc/pipeline/steps/workflow-scm-step/ makes it sounds like the branches option specifies which branches to monitor for changes, after which all branches are fetched. This still seems like a counter-intuitive design that doesn't fit the most common cases.

Reasons I'm suspicious:

* article leads with "in production" but it sounds like they are still at the design phase. production of prototypes maybe?

* they are doing a lot of "talking" and "partnering" but not so much selling mentioned.

* they are "known for" their similar work in the ultra-capacitor market but the linked page's top comment is "still waiting for a product".

* PR about raising funding and starting soon but not a lot of PR about actual products and results.

Am I being too cynical - does anybody know if they are for real?

The claim was not that they can't reduce but that an 80% discount was too much to ask of people (and thus also their families). I don't think anyone at any pay level would be happy being paid 20% of similar roles. Perhaps the problem was putting people in these roles in the first place that would accept 20% of market rate. Raising their pay subsequently doesn't make them better at their job!

The quote is not really crazy:

"Executive compensation is a general topic -- are execs, esp CEOs paid too much? I'm of the camp that thinks the different between exec comp and other comp is high. So then i think, OK what should mozilla do about it? My answer is that we try to mitigate this, but we won't solve this general social problem on our own. Here's what I mean by mitigate: we ask our executives to accept a discount from the market-based pay they could get elsewhere. But we don't ask for an 75-80% discount. I use that number because a few years ago when the then-ceo had our compensation structure examined, I learned that my pay was about an 80% discount to market. Meaning that competitive roles elsewhere were paying about 5 times as much. That's too big a discount to ask people and their families to commit to."

https://answers.thenextweb.com/s/mitchell-baker-aGY62z?comme...

The article's data is until 2018/2019. So, unlike some commentary suggests, this is before the pandemic/job cuts. Mozilla is for sure not in a good place though.

But that is by far the most common modern usage of the term. I would almost say the neutral usage is deprecated.

I wonder if ~10% of current F-150 sales are hybrids, or if they are really projecting for this model. I'd think people would consider going hybrid for the increased power outlet capacity, which could substantially alter the sales vs previous generations.

Who started this "exclusive" nonsense? This article suggests Spotify made some moves before Apple started:

https://www.theverge.com/2019/7/16/20696666/apple-podcast-ex...

Parent comment: “we don't know enough either way about reinfection risk at this point”

Are you disagreeing or did you miss that?

That all seems well-intentioned and plausible in terms of how things should have been originally. However,

1) I can't help but think of all the problems that apply in general to specifying requirements (too vague, too constraining, too expensive to hammer out to sufficient precision).

2) That's different from changing it retroactively. Would you change it again when JSON goes out of fashion? Or mandate HTTPS? I've not read the OP in detail, but the impression I have is that the existing service is very much functional. Even ignoring the cost of changing the law, do we really want our public institutions to be in breach of law whenever fashions change? I'd rather let them set their own priorities to a large extent - for example, specify a very general, minimal set of requirements and do better when they have capacity to do so. I'm fine with people building on top of that where convenient. It seems like a good thing, in fact.

You'd enshrine in law a particular technical format? What is the cost of making such a law vs the cost of a different - but still very much usable - format?

I think that's a point which is bordering on religious - many people would debate trusting the compiler, especially over time and more complex situations.

I'd certainly tend to agree with you in general but more for the reason that the compiler can abstract over hardware changes across time. I'd take that benefit over the risk of the optimisation not being applied for most code I write - non-optimisations would be considered bugs and probably/eventually fixed.

I'd strongly disagree the code is more complex (in this case).

Right: for now, in certain situations, on the tested toolchain.

Even ignoring those caveats, several commentators seem to have got the impression that this applies to the CPU.

Am I mis-reading this? The article keeps claiming there is no difference but the way I read it the compiler(s) are transforming mul/div to shifts. i.e. it very likely is faster on the hardware but it won't matter for this particular toolchain because of the conversion.

I'm not sure what you mean. The absolute difference appears to have shrunk considerably vs old hardware, based on this single, unreliable example. Probably most people care more about that than the relative difference? It's not explicit in the question (and neither are the benchmarks production-sized builds).

It matters a lot for the absolute numbers. Apparently not for the relative ones (my measurements were super noisy though).

Interesting - I didn't know the site gave those numbers at all. Obviously they are not the ones in the main comparisons.

Something seemed a bit weird with those numbers to me. My heavily loaded 2015 MacBook Air, which is also overheating, took <5s to compile nbody with the same Rust version and command line. The ratio remains about the same though - a similar GCC version is also much faster. Turns out, the hardware is really, really old ("Measured on a quad-core 2.4Ghz Intel® Q6600® with 3.8 GiB of RAM and 250GB SATA II disk drive; using Ubuntu™ 19.10 Linux x64 5.3.0-29-generic.").

I don't know why people feel the need to downvote instead of clarify, but this page is about runtime speed. The article is about compilation speed.

You can file an issue/PR in most cases, and if you don't get a response you may need to worry about moving libraries.