2,952 karma · joined May 3, 2012
It's just that I've just seen no such evidence that there's any Snowden-style 'betrayals of the public' happening in this particular instance. Maybe I'm wrong, and maybe I'm overly trusting, but I like to default to innocence until evidence of guilt is on the table.
That's a rather extreme claim, isn't it?
Are you saying that governments should widely publish all defense research? Are you saying governments should widely publish and distribute military plans before putting them into action? Are you saying governments should publish the locations of all defensive and offensive weaponry, as well as constant position updates of all military submarines?
That kind of openness would be suicidal. I agree that governments should encourage transparency, but not when that transparency would endanger lives etc.
Shining a light on this too early (assuming this wasn't an intentional "leak") could be akin to applying antibiotics to an infection prior to actually knowing what exactly the infection consists of, and discontinuing the treatment too soon (we all know how short the attention span of our news cycles are).
It doesn't seem unreasonable to analogize fighting spy networks to fighting an evasive infection: If you attack the infection with a half-baked or inconsistent treatment, you risk just breeding stronger infections that are even better at evading you.
Maybe I trust the US intelligence agencies too much, but it seems likely that they know what they're doing here. And so far, I've seen no evidence contrary to my default assumption that they're operating in best faith for the interests of the US and its citizens in this case.
To make an analogy: What if a newspaper was given sensitive personal information about someone that was legal to publish, but could have damaging effects to that person and the population as a whole if published too soon? Do newspapers have a civic responsibility to hold off on publishing information that would only be damaging to everyone (at least until it's safe to do so)?
* If the story is false, it's irresponsible because it causes severe monetary and reputational damage to companies that do not deserve it (e.g. Supermicro's stock is still down ~ 40%).
* If the story is true, it's a MAJOR breach of classified information from US intelligence operations; operations which I assume (without evidence to the contrary) are operating in good faith -- in the interest of the US and its citizens. Breaching classified information of such ongoing investigations to trace supply chains of spy chips could very well compromise those investigations (which would be irresponsible to risk).
So either way, it's irresponsible IMO.
P.S. IMO you cannot justify leaking this kind of info by comparing to Snowden, for example, because Snowden was a whistle-blower revealing information about operations that compromised citizens rights, which even congress was lied to about.
Native IRC clients for example have no such problem, and consume ~0% CPU at all times.
IMO: Text chat with a few emojis and images here and there should not ever be among the things that slows your computer to a crawl.
EDIT: I'm speaking of the UI, not the network connection; the latter is sometimes slow too, but that's understandable
Not if you expel an excess 500 calories per day on the toilet. This is what would happen if you chug a glass of olive oil, for example -- your body won't digest it all, and the vast majority of it will pass straight through.
This is an extreme example, but I make it to demonstrate a point 'calorie couters' always seem to forget: You keep assuming that you retain 100% of the calories you ingest, minus what you burn. This is demonstrably incorrect.
> If he were to eat that well calculated amount of olive oil everyday his weight would stay constant.
A source for this is needed. The study you provided, as far as I can see, says nothing of this. You're just assuming it's true, and I don't understand how/why.
My point was that the type of food your calories consist of does matter. If you do nothing but drink olive oil and multivitamins, you will lose a lot of weight and eventually starve to death, no matter how many calories you consume. The point is that the type of food you eat does matter to weight gain/loss (not only the calorie count), because the type of food affects how many of those calories you actually retain.
As far as I can see, this study provides no evidence (nor attempts to) that a diet consisting of nothing but olive oil can sustain your weight. I think it's quite well accepted that different kinds of food will be retained to differing degrees in your body (or put another way, different types of food will end up being passed through your system in differing percentages -- as well as with differing degrees of nutritional satisfaction per calorie ingested).
I'm not sure how you think this corroborates your claim that you can sustain your weight by drinking olive oil and water (+ multivitamin). In fact, I don't see anything remotely relevant to this in the study.
You're claiming that a human can viably survive their whole life by consuming a daily diet of:
1. Olive Oil
2. Multi-Vitimin
3. Water
> People had stable weight without any special knowledge for most of human history.
A lot of food products highly available today would be rather foreign to most of human history: artificially high sugar, high cab, low fat, snacks everywhere, etc.
These trick our taste and hunger systems into eating more of less quality foods than we would "naturally" if exposed only to less "engineered" foods, like pure meat and vegetables.
> It's something we generally should know how to do automatically.
Maybe we should, but clearly we do not. At least with modern processed foods that are optimized and designed to maximally stimulate our flavor response while compromising nutrition/health (generally).
That's like saying "There are no secrets to space flight: For every action, there is an equal and opposite reaction. It doesn't matter if that involves Hydrogen, Hydrazine, or just big tubs of water -- throw them one way, and you'll move the opposite. Your choice of fuel doesn't change physics."
Of course fundamental physics laws hold. But some fuels and systems of using those fuels are more effective than others.
When it comes to diet, different foods and eating patterns do have different effects on our endocrine system, and that does affect how viably we can sustain ourselves on less calories. Different foods will also have different proportions that are retained vs passed the same day.
Unless you also capture ALL your own human waste, and measure it in a 'bomb calorimeter', counting calories (intake only) is not nearly as useful as you seem to think. If you disagree, drink 2000 calories of olive oil every day and eat nothing else, then come back after a year and tell me that calories are all that matter :) Disclaimer: Don't actually do that, because you would starve to death.
Yes there’s a lot of “bias hysteria” out there, as you put it, but I would dispute that advocating “author-blind meritocracy” falls into that category.
Quite the contrary: An author-blind review process would actually make any bias impossible — either for or against any particular identity group. It seems to me most people should be able to get behind that, but maybe I’m wrong.
In fact, the main opposition to author-blind meritocracy is the “post-meritocracy” movement which is slowly making its way into open-source projects codes of conduct.
I’m not sure what the best alternative should be, though. I am a fan of open source work as a sort of code portfolio, but it doesn’t work for every kind of engineering/science (edit: and also would introduce bias against professionals too busy for open source.)
Regarding bias — it seems the only way to truly eliminate it (including unconscious bias) is author-blind reviews, i.e. reviewing code written by a candidate without knowing anything about that candidate’s identity. (And the nice thing about code is it usually doesn’t signal any identity traits of the author via side channels.)
There are plenty of cases where you'd prefer an application to crash upon an unhanded write error, rather than silently losing data that could be highly important and irrecoverable.
(Of course, actually handling the errors is preferred above both.)
> Destructors aren't supposed to fail.
But isn't the whole point of this discussion is that the destructor of fs::File (and probably any other buffered IO writer) can and does fail in some cases?
I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree?
I certainly was not aware that drops in Rust could throw away potentially serious error codes. Now I have to go re-audit the correctness of all my Rust code that uses the file system (at the very least).
If the behavior was documented I would not consider this a bug. That said, perhaps I’m missing something in the documentarion — my apologies if thats the case — but I did just re-read the fs::File docs and see no mentions or precautions about potential data loss when a File is dropped.
Perhaps I misread this documentation; if so, I don’t think I’d be alone here. I don’t see any particular mention that dropping an fs::File could lead to data loss, and I had generally assumed major edge cases like ‘data loss from a file system library’ would be documented.
Letting this slide for this long is a very bad sign. I’ve been a big Rust fan for my hobby projects, but the whole point of Rust is effortless correctness and safety. The more I encounter bugs and issues that have no near term solution planned, the more confidence I must admit I’m losing in their bug vs feature work prioritization scheme.
For example, it seems sometimes that Rust management would rather focus on cool new language enhancements / rewrite projects, than fix major bugs (sometimes even major borrow checker bugs, or random segfaults created in correct programs).
For example, what if time does not necessarily flow in a single direction at the quantum scale; what if instead, the ground level of physical reality is a timeless information graph / equation that is 'solved by the universe'?
I'm no physicist and no nearly nothing about the real math of QM, but every time I read these lay-explanations of "quantum weirdness" and "wave function collapse", I get this strange feeling that we're thinking about time all wrong: What if unidirectional time is an illusion? What if causality (and inference) is an illusion (thus explaining how hard it is to capture it mathematically)?
It is precisely because Rust makes it difficult to implement a lot of bad ideas, that I find myself spending a tiny fraction of my time debugging Rust applications vs C/C++/others (including even high level GC languages).
I love that Rust encourages inherently reliable code, while also not stopping you from writing "unsafe" blocks in the (rare) cases where they're necessary. In fact, in every case so far where I thought 'maybe I should try an unsafe block', I started to realize that implementing this idea or data structure was actually riddled with hard memory management problems, or race conditions, etc. that Rust was preventing from even being possible at all.
P.S. Of course there's a steep learning curve to Rust at first, but it's not fair to count that against Rust -- unless you also weigh against C++ all the years it takes to really master it. IMO, Rust's learning curve is far less steep and painful than C++, it's just that many of us are biased and comfortable having already climbed the C++ learning cliff (so we tend to forget it is there, and how bad it is).
I think most people definitely underestimate the amount of caution / design care required to implement even something as simple as a linked list with zero bugs, memory leaks, potential infinite loops in member functions, etc.
The Rust compiler prevents entire classes of bugs at compile time, and just requires that you to write an 'unsafe' block if you really want to go ahead with this sort of code without the compiler complaining. This emphasizes that you really do have to be careful and think through the logic and memory ownership semantics of the code you just wrote. People used to GC'ed languages will find this annoying to have to worry about at all, but that is inherently the price you must pay to eliminate GC pauses/overhead.
I'm not saying you should never use data structures that Rust makes hard to write, but that going into Rust thinking it's just going to be 're-skinned C++', or 'as easy as a GC language' is going to be a recipe for disappointment. If you allow yourself to learn a new way of thinking about low/systems-level coding, you may be pleasantly surprised. But if you're too "set in your ways" (whether it be of C/C++ or JS/Python/etc.), you're not going to see Rust's benefits.
Rust is a deeply different language than C/C++. I think people forget this, primarily because Rust is so powerful and efficient (with no inherent language overhead, allowing it to be used even in embedded environments and other systems programming tasks).
Going with AMD at this point is simpler, better for security, and if you care about this sort of thing -- rewards more honest and less consumer-predatory behavior. I've always gone with Intel my whole life, but given these many incidents with Intel, combined with their really poor public responses to it, I will now be switching to an AMD user for all future PC builds.
And if you use them a lot, I can only imagine they’ll be like the display models at Home Depot / Lowe’s: Lutron Caseta buttons wobbling loosely as if they’re about to fall off, while GE rocker style switch is just fine.
THAT explains why Netflix keeps recommending me garbage quality content! I had a suspicion this was true, but couldn’t imagine anyone would make such a terrible design choice: 95% of content Netflix recommends me now is unwatchably bad in content quality (including Netflix originals too, of course).
IMO abolishing user ratings is quite probably the worst possible solution to losing user engagement due to low quality content.