Joking, but not that much :)

As far as I know, access points only identify via their SSID. Which is a string like "Starbucks". So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.

Aka "unknown" or "public" Network....don't do that.

[1] except availability, we still can't get it right in setups used by regular people.

And when you connect to a non-public WiFi for the first time - how do you make sure it is the WiFi you think it is and not some dude who spun up a hotspot on their laptop?

I guess my point is the way the internet works is that your traffic goes through a number of unknown and possibly hostile actors on it's way to the final destination. Having a hostile actor presenting a spoofed wifi access point should not affect your security stance in any way. Either the connection works and you have the access you wanted or it does not. If you used secure protocols they are just as secure and if you used insecure protocols they are just as insecure.

Now having said that I will contradict myself, we are used to having our first hop be a high security trusted domain and tend to be a little sloppy there even when it is not. but still in general it does not matter. A secure connection is still a secure connection.

Take eduroam, which is presumably the world's largest federated WiFi network. A random 20 year old studying Geology at Uni in Sydney, Australia will have eduroam configured on their devices, because duh, that's how WiFi works. But, that also works in Cambridge, England, or Paris, France or New York, USA or basically anywhere their peers would be because common sense - why not have a single network?

But this means their device actively tries to connect to anything named "eduroam". Yes it is expecting to eventually connect to Sydney to authenticate, but meanwhile how sure are you that it ignores everything it gets from the network even these low-level discovery packets?

Additionally, eduroam uses certificate auth baked into the provisioning profile to ensure you are authenticating using your organizations IdP. (There are some interesting caveats to this statement that they discuss in https://datatracker.ietf.org/doc/html/rfc7593#section-7.1.1 and the mitigation is the usage of Private CAs for cert signing).

Another fact is that the money saved went to fund a (small) portion of the big beautiful bill, which doesn't exactly focus on helping the average american Joe.

It’s researchers who are not at the top of their fields who will have a much harder time leaving America to find research positions, since academic positions and funding haven’t been easy to obtain in places like Canada, Europe, Australia, and Japan for at least two decades.

What will most likely be the case is that scientific careers will be halted temporarily or permanently from these funding cuts. Graduate admissions are harder than ever now, it’s harder to find a research position, and I can’t imagine how much more difficult tenure will be to obtain if professors can’t fundraise and publish. Industry isn’t always an option, either. A lot of researcher’s careers will face major setbacks, some unrecoverable, all due to the capriciousness of our rulers.

For example the anti-swastika or anti-cult laws, which I am not against, it's just a different approach to something like this happening

In the abstract. In actual practice, it's not clear, and you could even build quite a strong case for the opposite view. "Cancellation" over mere words has been commonplace for over ten years, and is much more common to the US than to Europe. And as for laws... What just happened to Tao and UCLA has, to the best of my knowledge, never taken place in Europe in recent decades.

Oh, so I can freely go up against the German government's policies and have my career in academia unaffected and keep my government funding?

I lived in Germany and don't remember people or organisations ever being able to break government rules with no consequences (unless they had high friends in politics).

Something smells here.

I'm sure the German government will react with much more leniency than the US.

AFAICT, no German academic institutions have lost funding as a result of the student's protests. Those protests were stopped, police action etc., but no funding change to the academic institutions.

I lived in Germany and the moment you don't do what the government says you get the full shaft. Nobody let's you rebel against the government with no consequences, not in US, not in Germany, not in UK, nowhere.

People painting Germany like a bastion of free speech are coping hard. Only if you consider free speech doing and saying only what the government says.

What about Christian Drosten who criticized a lot of the Corona decisions, Jan Boehmermann who is very critical but still employed by state-financed TV. Fridays for Future?

What did he criticize? Did he ever criticize all the crimes due to illegal migrants? Of course not because that's not allowed by the state.

He is just a government mouthpiece acting like a jester to give people the illusion that the government allows criticism, but he's not a proper critic of the government, as those are banned.

Other countries like the way the US used to be 15 years ago? Is your argument really "other people don't have rights, therefore we shouldn't either"?

However, in this case, it's quite hard to argue that Terrence Tao had anything to do with antisemitism or anything against Trump's policies. Actually I don't think Terrence Tao did anything that Trump cared about. This isn't really a free speech issue, it's more like some fundamental instability in the US, and maybe the US government is running out on money and trying to cut down on research expenditure using excuses.

Sounds like a feature, not a bug.

> And when I say Europe, I mean UK, France and Germany.

Europe is much larger and more diverse than those three countries. Scandinavia for example consistently top the list in most well-being statistics.

In fairness, it can be either, and which it is depends if in the specific case it's more accurate to phrase it as "the ruling classes are on the side of the universities" (good) or as "the universities are on the side of the ruling class" (bad).

It's never been any different, all the way back to when Germans or Irish or whoever were the 'demonized immigrants'. This is what made America great. Anytime we want it, those conditions can return. It was no illusion.

On the front of funding research? Considering that one is constantly adding more funds for research, while the other one is removing funds, I'm not sure how accurate that is.

If you truly believe that the whole world is "just as bad" as this, then you are unimaginably far to the right.

If you're fully aligned, there's no telling what would happen if you weren't, and you can't use "nothing happens" as evidence that nothing would happen - you're always allowed to share the opinions of whoever funds you.

If Germany got a right-wing government on the federal level, I expect to see either funding being slashed or universities adjusting their positions.

It's silly to say that EU is better jut because people don't see the government interfere with universities in the EU, when EU universities would never go against the central government to begin with, because that's where all their money comes from. Why would you bite the hand that feeds you?

Meanwhile universities like Harvard have so much private money they can publicly tell Trump to shove it. EU universities don't have this privilege so they exercise a degree of self censorship based on how the government tells them to dance.

Would you please expand on this?

Or Dutch professors openly criticizing the plans by the right-wing government (which just fell) as being damaging, unproductive amd sometimes unconstitutional?

The only examples I see are the opposite of what you say. Can you name any examples in Germany, Sweden, Norway or Holland? (Those are the countries that I'm confident talking about at least)

I genuinely wonder if you actually have ever written c/c++, there is plenty of code that is perfectly valid and safe (mostly involving multiple pointers to mutable memory being alive) that the borrow check cannot accept because it has to draw a line to things it can prove are correct.

It's like saying that the only valid math is the one that an automated theorem prover can prove, it's not even close to being true.

I have; enough for one lifetime if you ask me. It was hunting use after delete which made me stop.

I kinda agree with you, with the caveat that both can be true. If you want to write safe-ish C++ you’ll use defensive containers from the start and watch iterators like a hawk. You can also take a more cavalier approach and live with the consequences (which might not happen and then you win big).

Rust wants you to basically not use references unless your data fits the one writer xor many readers model (painfully including struct members, recursively) and the cavalier approach is very strongly discouraged on the language level. This forces you towards safety, but I also agree with everyone else who say that isn’t how computers actually work. The impedance mismatch is an engineering tradeoff to make.

There are many actions and behaviours in life that are not illegal but actively worsen society at large if you do them. That companies that are the main contributors to OSS are forced to take drastic measures is just consequence of AWS not being a team player, you should have at least the decency of not commenting here.

PS. I don't have a horse in the race, I'm not a Redis user, I'm just appalled by your behavior.

Namely, in Rust it is undefined behavior for multiple mutable references to the same data to exist, ever. And it is also not enough for your program to not create multiple mut - the compiler also has to be able to prove that it can't.

That rule prevents memory corruption, but it outlaws many programs that break the rule yet actually are otherwise memory safe, and it also outlaws programs that follow the rule but wherein the compiler isn't smart enough to prove that the rule is being followed. That annoyance is the main thing people are talking about when they say they are "fighting the borrow checker" (when comparing Rust with languages like Odin/Zig/Jai).

Not that I'm such a Rust hater, but this is also a simplification of the reality. The term "fighting the borrow checker" is these days a pretty normal saying, and it implies that the borrow checker may be automatic, but 90% of its work is telling you: no, try again. That is hardly "without needing to do much extra at all".

That's what you're missing.

Because this phrase existed, it became the thing people latch onto as a complaint, often even when there is no borrowck problem with what they were writing.

Yes of course when you make lifetime mistakes the borrowck means you have to fix them. It's true that in a sense in a GC language you don't have to fix them (although the consequences can be pretty nasty if you don't) because the GC will handle it - and that in a language like Jai you can just endure the weird crashes (but remember this article, the weird crashes aren't "Undefined Behaviour" apparently, even though that's exactly what they are)

As a Rust programmer I'm comfortable with the statement that it's "without needing to do much extra at all".

This being said, yes Rust is useful to verify those scenarios because it _does_ specify them, and despite his brash takes on Rust, Jon admits its utility in this regard from time to time.

Nah, it's going to be Undefined. What's going on here is that there's an optimising compiler, and the way compiler optimisation works is you Define some but not all behaviour in your language and the optimiser is allowed to make any transformations which keep the behaviour you Defined.

Jai uses LLVM so in many cases the UB is exactly the same as you'd see in Clang since that's also using LLVM. For example Jai can explicitly choose not to initialize a variable (unlike C++ 23 and earlier this isn't the default for the primitive types, but it is still possible) - in LLVM I believe this means the uninitialized variable is poison. Exactly the same awful surprises result.

1. because it is the kind of optimizing compiler you say it is

2. because it uses LLVM

… there will be undefined behavior.

Unless you worked on Jai, you can’t support point 1. I’m not even sure if you’re right under that presumption, either.

What other kind of optimisations are you imagining? I'm not talking about a particular "kind" of optimisation but the entire category. Lets look at two real world optimisations from opposite ends of the scale to see:

1. Peephole removal of null sequences. This is a very easy optimisation, if we're going to do X and then do opposite-of-X we can do neither and have the same outcome which is typically smaller and faster. For example on a simple stack machine pushing register R10 and then popping R10 achieves nothing, so we can remove both of these steps from the resulting program.

BUT if we've defined everything this can't work because it means we're no longer touching the stack here, so a language will often not define such things at all (e.g. not even mentioning the existence of a "stack") and thus permit this optimisation.

2. Idiom recognition of population count. The compiler can analyse some function you've written and conclude that it's actually trying to count all the set bits in a value, but many modern CPUs have a dedicated instruction for that, so, the compiler can simply emit that CPU instruction where you call your function.

BUT You wrote this whole complicated function, if we've defined everything then all the fine details of your function must be reproduced, there must be a function call, maybe you make some temporary accumulator, you test and increment in a loop -- all defined, so such an optimisation would be impossible.

NLL's final implementation (Polonius) hasn't landed yet, and many of the original cases that NLL were meant to allow still don't compile. This doesn't come up very often in practice, but it sure sounds like a hole in your argument.

What does come up in practice is partial borrowing errors. It's one of the most common complaints among Rust programmers, and it definitely qualifies as having to fight/refactor to get obviously correct code to compile.

For some people. For example, I personally have never had a partial borrowing error.

> it definitely qualifies as having to fight/refactor to get obviously correct code to compile.

This is not for sure. That is, while it's code that could work, it's not obviously clear that it's correct. Rust cares a lot about the contract of function signatures, and partial borrows violate the signature, that's why they're not allowed. Some people want to relax that restriction. I personally think it's a bad idea.

People want to be able to specify partial borrowing in the signatures. There have been several proposals for this. But so far nothing has made it into the language.

Just to give an example of where I've run into countless partial borrowing problems: Writing a Vulkan program. The usual pattern in C++ etc is to just have a giant "GrahpicsState" struct that contains all the data you need. Then you just pass a reference to that to any function that needs any state. (of course, this is not safe, because you could have accidental mutable aliasing).

But in Rust, that just doesn't work. You get countless errors like "Can't call self.resize_framebuffer() because you've already borrowed self.grass_texture" (even though resize_framebuffer would never touch the grass texture), "Can't call self.upload_geometry() because you've already borrowed self.window.width", and so on.

So instead you end up with 30 functions that each take 20 parameters and return 5 values, and most of the code is shuffling around function arguments

It would be so much nicer if you could instead annotate that resize_framebuffer only borrows self.framebuffer, and no other part of self.

That's correct. That's why I said "Some people want to relax that restriction. I personally think it's a bad idea."

> The usual pattern in C++ etc is to just have a giant "GrahpicsState" struct that contains all the data you need. Then you just pass a reference to that to any function that needs any state.

Yes, I think that this style of programming is not good, because it creates giant balls of aliasing state. I understand that if the library you use requires you to do this, you're sorta SOL, but in the programs I write, I've never been required to do this.

> So instead you end up with 30 functions that each take 20 parameters and return 5 values, and most of the code is shuffling around function arguments

Yes, this is the downstream effects of designing APIs this way. Breaking them up into smaller chunks of state makes it significantly more pleasant.

I am not sure that it's a good idea to change the language to make using poorly designed APIs easier. I also understand that reasonable people differ on this issue.

What they're describing is the downstream effect of not designing APIs that way. If you could have a single giant GraphicsState and define everything as a method on it, you would have to pass around barely any arguments at all: everything would be reachable from the &mut self reference. And either with some annotations or with just a tiny bit of non-local analysis, the compiler would still be able to ensure non-aliasing usage.

"functions that each take 20 parameters and return 5 values" is what you're forced to write in alternative to that, to avoid partial borrowing errors: for example, instead of a self.resize_framebuffer() method, a free function resize_framebuffer(&mut self.framebuffer, &mut self.size, &mut self.several_other_pieces_of_self, &mut self.borrowed_one_by_one).

I agree that the severity of this issue is highly dependent on what you're building, but sometimes you really do have a big ball of mutable state and there's not much you can do about it.

1. The borrow checker is indeed a free lunch 2. Your domain lends itself well to Rust, other domains don't 3. Your code is more complicated than it would be in other languages to please the borrow checker, but you are unaware because its just the natural process of writing code in Rust.

There's probably more things that could be going on, but I think this is clear.

I certainly doubt its #1, given the high volume of very intelligent people that have negative experiences with the borrow checker.

Just like any programming paradigm, it takes time to get used to, and that time varies between people. And just like any programming paradigm, some people end up not liking it.

That doesn't mean it's a "free lunch."

Again this person has no trouble understanding the BC, it has trouble with the outcome of satisfying the BC. Also this person is writing Vulkan code, so intelligence is not a problem.

> is quite common and widely understood

This is an opinion expressed in a bubble, which does not in any-way disprove that the reverse is also expressed in another bubble.

For the rest you need more granular manual memory management, and defer is just a convenience in that case compared to C.

I can have graphs with pointers all over the place during the phase, I don't have to explain anything to a borrow checker, and it's safe as long as you are careful at the phase boundaries.

Note that I almost never have things that need to survive a phase boundary, so in practice the borrow checker is just a nuissance in my work.

There other use cases where this doesn't apply, so I'm not "anti borrow checker", but it's a tool, and I don't need it most of the time.

(To be clear I agree that this is an easy pattern to write correctly without a borrow checker as well. It's just not a good example of something that's any harder to do in Rust, either.)

Edit: reading wavemode comment above "Namely, in Rust it is undefined behavior for multiple mutable references to the same data to exist, ever. And it is also not enough for your program to not create multiple mut - the compiler also has to be able to prove that it can't." that I think was at least one of the problems I had.

> reading wavemode comment above

This is true for `&mut T` but that isn't directly related to arenas. Furthermore, you can have multiple mutable aliased references, but you need to not use `&mut T` while doing so: you can take advantage of some form of internal mutability and use `&T`, for example. What is needed depends on the circumstances.