fghvbnvbnfe

I don't think you can point at a specific action, but the leaked (Podesta, I think) emails seemed to show that the DNC was working to help the Clinton campaign to the detriment of Sanders during the primary. This lead to the resignation of Debbie Wasserman Schultz from the DNC chairman position.

Later, it turned out the Clinton campaign had essentially taken over the DNC far in advance of the primary results which is highly unusual, to the say the least. [1]

[1] https://www.politico.com/magazine/story/2017/11/02/clinton-b...

The idea here is to make a clear split between owning and licensing. If the company decides they are selling the items themselves then the items should be repairable by the new owner. If the company decides they are merely selling the rights to use the items then it is reasonable for the user to be unable to repair it, provided the owner (the company) is willing to keep it in working condition.

That should absolutely include wear and tear as well as accidental damage. Intentional damage is an issue, but there shouldn't be much motivation for it under such a system.

I don't think there needs to be parity between the prosecution and defense in this matter. Those technicalities on the defense side serve to help protect the rights of the accused, while on the prosecution side they just obscure the truth of the matter.

That's not really a meaningful argument. You're talking about a large multi-cellular organism that has tissues, organs, and all that and comparing it to something that doesn't even have cells.

> The difference here is that neo-nazis make a decision to be bigots. They could stop. Most LGBT people consider their status to be a matter of birth.

I don't understand why this argument gets thrown about so often. Obviously not so much about neo-nazis in particular, but whenever a comparison is made to LGBT people. And before anybody jumps to conclusions, I am not about to argue that sexual orientation is a choice.

Even in the face of overwhelming evidence of all kinds, from all sorts of sources, there are people that seem to honestly believe the earth is flat. There is no way to make a reasoned decision to believe that. It must be something they are not in control of. It could be something they were born with, something in their experiences, or both, but it's clearly something they are not rationally deciding.

I'm not certain it can be said that the neo-nazis are definitely making a choice. It seems to be a pretty vehement emotional response, which would indicate it's not.

I don't mean to say we should tolerate neo-nazis in the sense that we just let them do their thing. But I do think we might be better off treating them as people that have some predisposition to being neo-nazis than as people that just decided to be one.

I don't understand the extreme focus on brevity, though it does seem to be mentioned regularly. In practice I don't notice a difference between "begin" and "{". It's not something I have to think about, and my typing speed exceeds the speed at which I'm able to determine what to type next.

I understand avoiding excessive amounts of large boiler plate where standard patterns are constantly repeated for no particular reason, but that's not a comparable situation to individual keywords.

Did you figure out why customers would leave? I've been thinking about doing something in the "most people use a spreadsheet" space and hearing that people went back to it after a year of using a dedicated product is a little worrying.

Do you feel bad for using any of the multitude of tax-payer funded services available?

Taxes are already pretty divorced from use of the services they pay for. People with more money than you have had more of it "forcefully" taken from them to pay for the roads, emergency services, and so on that you use.

I don't think there's much predictive power there. The people who are answering thousands clearly just haven't though about it before and are on the spot. Humans are just terrible with big numbers, and thousands sounds like a lot already.

You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?

I agree that it is "useless trivia."

The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases.

Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how fast the program will run.

It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question.

Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.

I agree with you in general, but not when only talking about the mathematical understanding.

If you want to add fractions by individually adding the numerators and denominators and the only reason you don't is one of these checks, you have some kind of fundamental lack of understanding about fractions. It's great that you are wise enough to verify, but that's irrelevant to your mathematical understanding.

I've always done those quick checks myself because otherwise I'm prone to making errors. They give me a quick answer of "no, you can't do this" but I never found they actually improved my understanding of anything. It just told me I can't do the thing I wanted to do and it was time to move to the next idea. It's a valid proof, but not one that really ever helped me get a grasp on what's happening.

Mostly it just means I'm in trouble and need to be really careful and do more checks because I'm working with things I don't understand fully.

For example, I've never needed to do that sort of check with adding fractions. I have enough understanding of what those numbers represent and how they work together that I've just never thought I might want to add numerators and denominators separately.

That's not really relevant. You only need to check if the equations hold if you don't understand the math involved. You've already lost at that point.

Checking is the smart thing to do then, but ideally what is important is the understanding rather than just the diligence to make sure a guess isn't trivially shown incorrect.

What do you think his right hand might be doing? I'm not familiar with the Tesla interior setup so I don't know what is possible, but I'm having a hard time imagining what he could be possibly be doing off-camera that wouldn't be reflected in any of the visible displays.

And meanwhile I've been having no trouble with Firefox, but had to stop using Palemoon because too many websites were breaking consistently.

Yes. That single pouch is a significant problem when you generate several a day. They are intended to be used for meal prep, which involves hot water. They're fairly heavy and large, and you have to carry them out with you. You can save a significant amount of weight when packaging your own food by using smaller, lesser weight bags with a separate reusable insulator. Remember, we're talking about people that will pay a significantly higher price for an item that is maybe an ounce or two lighter.

It also gives you a lot more control over portions, which can be an issue as well. There is no point packing more than you are going to eat.

I brought up the salt content not for health reasons, but taste. Many of the ones I've tried have been so salty I've had trouble finishing them even after a day of backpacking.

Those are really not alternatives to the mentioned uses. The freeze dried food selection is somewhat limited, tends to be very salty, takes substantially more time to prepare, and generates a lot of waste you get to continue hauling around.

If your goals include speed or (less) weight, those freeze dried options are really far from ideal. To get around the weight issue you mostly need to plan and package your food yourself, which takes some time. If you're getting called out to do SAR you either need to have it done in advance or go with another option.

Of course you can compare them. I didn't mean we shouldn't ever look at the differences in how languages do things. We should. I meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals.

And I've seen that before. Frankly I thought it overly nice to Rust by not spending any time at all considering the differences in user-defined types. That's really one of the biggest and most important differences to me, and a place I think Rust really falls short.

Ada addresses memory issues in a couple ways. In a general sense, the language is designed to prevent the need for explicit allocations and pointers as much as possible. The runtime uses a secondary stack to return dynamically-sized objects from functions. The low level parameter passing details are also compiler-controlled. The programmer specifies how an argument is used (input, output, or both) and the compiler deals with how to accomplish that. There are some other features (mostly related to types and bounds) that all combine to generally reduce the need for explicit memory management.

Once you do get to explicit memory management, Ada does a number of things. I'm going to a list here just for my own sanity.

First, all deallocations are essentially marked unsafe. You use Unchecked_Deallocation() to free memory.

More importantly, it provides memory pools, and subpools. Each pointer type can be associated with a pool (or subpool). Once the pool goes out of scope, all memory is freed. You can use this to avoid explicit deallocations yourself. Pools also control allocations and deallocations, and there exist Debug pools that can help ensure memory is accessed correctly.

Ada also requires that stack-based objects be declared as "aliased" before you may make a pointer to them, so it's always clear where there might be trouble.

Finally (I think), Ada has a concept of accessibility levels. Essentially a pointer cannot point to an object that is more deeply scoped than itself. This isn't the perfection of the Rust borrow checker, but it does quite a bit.

As for C FFI, Ada does that quite well. It's got a package in the standard library with C interface types, and aspects for marking things for C FFI.

As as been mentioned, integer bounds for one. Using aspects in Ada will also let you provide other assurances (at compile time or runtime, depending).

Additionally, the "newtype" in Ada is far easier to work with. The new type inherits the operations of the parent type. When it comes to this sort of thing, it needs to be as simple and easy as possible or it just doesn't get done consistently.

Again here the word "safety" starts to get rather muddy. What Rust calls safe is not what Ada calls safe. I'd rather be specific about what we're talking about.

Memory safety is not, itself, program correctness. It's just one way programs can go wrong.

When things such as the borrow checker are so heavily built in to the language, I find it hard to to see how Rust isn't ultimately intended to do memory safety. Obviously it does other things, and I'm sure it has some cool ideas in there. But I have a hard time seeing how it's a mischaracterization of Rust to say that memory safety is kind of it's thing.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it.

They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada.

Rust is obsessed with memory safety. That's it's thing. Unsafe code aside, it's memory safe. And it tackles some concurrency issues too.

Ada is more concerned with overall correctness, particularly in terms of types, where the types are semantically meaningful. And it goes further and dips into memory safety and concurrency. It doesn't such an extreme tact as Rust, but it does an awful lot to provide good options that allow you to avoid many issues. And it generally tries to make programs easy to understand. And more - some of which, as the article notes, are really quite wonderful for going really low level.

Personally I see the most value in the semantic type safety. That's really been, in my own experience, where Ada has helped me the most. Many of the other features are also great. I just don't see almost any of it in Rust. You can sometimes get stronger guarantees about a few things and you kind of lose everything else.

How is that an alternative or a replacement? Yet this idea is everywhere.