I think it's the right call, given that they have a problem with Russian saboteurs who snuck into the country before the war started. They're currently discouraging the use of the Russian language (many Ukrainians speak both Ukrainian and Russian) to avoid suspicion. Tension is extremely high right now, checkpoints everywhere around Kyiv, guards on the edge, and there's a huge risk of escalation if you're suspected of being on the wrong side.
There's been many videos of alleged saboteurs getting arrested, and the rumor is that your ability to pronounce a Ukrainian word correctly is used as a test to find out where you're from.
The sadder truth may be that Russians might not be interested in removing Putin. Decades of propaganda, murdering of opposition, and authoritarian response to protests has grown a people that largely believes in their leader and is also afraid to openly oppose authority.
This is not true. Even just the opposition party leader Navalny is good enough. Good people exist in Russia. Putin just needs to be removed from the helm.
>This is not true. Even just the opposition party leader Navalny is good enough.
Yeah, only because he's anti-Putin. People who follow internal deals more closely remember how he was marching with slogans "Russia for russians, Moscow for moscovians" and such. He always was very opportunistic in my opinion.
I respect him for what he's done regarding investigations but he's not a president material.
>Good people exist in Russia.
Sure, but being a "good person" does not qualify you as president. No to mention that "good" is subjective. Many people see Putin as a good person.
There's also people who see it this way: world war 2 ended Hitler, world war 3 may be needed to end Putler. A war might be the only way to take out a genocidal dictator-terrorist who threatens the entire world with nukes.
Yes right, this is what I mean by "they find a way to be okay with it." Well-meaning and high-minded establishment types like Tom Friedman or Jeffrey Goldberg or David Frum wouldn't let themselves indulge in outright bloodlust; that would be too crass, too icky, and too honest. So they concoct little children's tales like "WW3 may be needed to end Putler" to rationalize it. This is an ego defense: a mechanism to protect against the anxiety of seeing yourself as something horrible (seeing yourself honestly, in this case).
Independently of whether it's a rationalisation or not, it might be the actual reality of the situation. Maybe WW3 actually _is_ needed to unseat him (though I hope it's not).
> And Ukrainans believe there's a "ghost plane" in the sky that destroyed half russian air force.
No, not a ghost plane. Just a nickname given to a pilot (though it could be multiple pilots) who allegedly shot down a handful of Russian planes in the first days of the war. "Ghost of Kyiv." There's uncertainty and a lot of speculation going on about this pilot's accomplishments (and identity), but that doesn't mean the Ukrainians are being told lies.
It doesn't have to be myth or lies and propaganda to be given a nickname. See also The White Death.
^Another example of a Ukrainian "myth" being a straight up lie. I haven't seen good data confirming Ghost of Kiev's kills....much like the "Russian Airborne lost 2x Il-76 transports full of paratroopers". I haven't seen pics of Il-76 crash sites. Seems odd, considering the huge amount of photos/video of coming out of the war, including plenty of other downed aircraft.
Can you say what exactly here is a straight up lie? That the Snake Island defenders were thought dead after contact with them was lost following the attack? That Ukraine claims there were 13 defenders while Russia claims there were 82?
There's a ton of things we don't have good video coverage of, including the Snake Island events, so it's very hard to verify any claims. This lack of certainty affects the belligerents too so -- unless you have conclusive evidence to show that deliberately false statements have been made -- I think it's quite arrogant to say "straight up lies" concerning statements that may have been made in confusion and without a full picture of the situation.
>>>Can you say what exactly here is a straight up lie?
Sure, right here: “Defending the Zmiinyi Island, all our border guards died a heroic death,” Zelensky said.
and: The guards will posthumously receive the "Hero of Ukraine," the highest honor Ukraine can bestow, Zelenskyy said. from ( https://www.foxnews.com/world/snake-island-soldiers-russian-... )
His comments left no room for ambiguity. How do you award medals posthumously without CONFIRMATION of death?
Now compare that to the military's actual statement: Ukraine’s State Border Guard Service took to Facebook to announce Snake Island had been captured and its infrastructure destroyed by shelling from a Russian ship on Thursday, adding communication with the guards had been lost.
THAT is the correct way to release a SITREP or pass message traffic: communicate only what you can verify to be true. The Border Guards are closer to the Ground Truth (tm) than the Head of State, so that's the message that should have been propagated, accurately, at all levels. But that's not a good enough morale booster, so some embellishment worked its way in as the story floated up the chain of command. And the consequence is now the Ukrainian Commander-in-Chief has egg on his face. That should NEVER happen.
I've spent years working with a Corps-level Operations Center, including months serving as the Senior Watch Officer. I've seen a LOT of sloppy messaging, confusion, and friction. We have battle drills that we rehearse for casualty reporting, CSAR (Combat Search & Rescue), and TRAP (Tactical Recovery of Aircraft Personnel). Clarity of information is paramount, and any decent Battle Captain (what the Army calls a Watch Officer) should know to ask "Who did this report come from?" and "How do we know that's true?" "Can we VERIFY that?" Or, for a bit of levity: https://youtu.be/oqrO1RtN4gADid you see...the body? You don't make assumptions, and you don't put your personnel spin on reporting.
The story went from "they lost comms" to "they were Killed in Action and we must award them the highest honors" in the blink of an eye. For them to be lying, is the more charitable assessment of events: the alternative, widespread incompetence from their Operations officers to their Public Affairs/Communications Strategy staff, would be far far worse.
> However, there may still be a number of corner cases of the language like undefined behaviors. This is why people frequently fall into C's traps.
I don't think that's true; the UB that is relevant for day-to-day programming is easily learned.
It's just that a sucker is born every minute and there's always someone who's been taught that C is a high level assembler. Now and then someone slips a piece of code that assumes as much in a project and disproportionately big noise is made about it.
Most UB-related bugs in C code are not there because the author didn't know it's UB, but because they simply coded it wrong. People fall into simple buffer overflows, double frees, etcetra all the time and no-one thought it's ok to overflow a buffer.
Right. All this buzz about UB is a bit much. Sure, it's not great to have to assume that something breaks when you upgrade your compiler when the compiler authors made a change to exploit some UB that I didn't know of.
On the other hand, I'm quite confident that I don't have much UB in my code (as running sanitizers from time to time confirms). And miraculously, I've never ever been surprised by "nasal daemons".
No, the problem of undefined behaviour isn't overstated. It's the reason C and C++ have such a poor security track-record.
> I'm quite confident that I don't have much UB in my code
Plenty of C and C++ programmers are confident they don't have UB in their code, and yet we see a constant stream of security issues arising from UB in codebases developed and maintained by the smartest and most motivated C/C++ programmers, such as kernel code and the Chromium codebase.
From the Chromium project: [0]
> Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.
These bugs are, of course, undefined behaviour. These are serious bugs that presumably made it through their code-review and code-analysis processes.
(Chromium is written in C++ rather than C, but the point stands.)
> running sanitizers from time to time confirms
It doesn't. Modern static analysis tools are pretty smart, but they're a long way from being able to detect every instance of possible UB, with no false positives. If they were, we'd be in a very different place.
With the current state-of-the-art, the only way we have of developing C/C++ codebases that are free of UB, is to use formal methods (e.g. SeL4). This approach is very rarely taken, on account of the impact on development speed, and the skill needed.
I feel you've missed my point. I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen. And while this is "undefined behaviour", it is not what people mean when they complain about UB.
> I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs
Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases.
There may also be many instances of easily-detected undefined behaviour that exist only because of sloppy software development. There may also be many instances of undefined behaviour that are relatively benign.
> and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen.
I don't think I'm seeing your point. We agree that undefined behaviour can have serious consequences.
> while this is "undefined behaviour", it is not what people mean when they complain about UB
I don't follow. Undefined behaviour is an unambiguous term of art in C and C++ programming. There are plenty of common misconceptions about UB, sure enough, but the term itself is precise.
> Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases.
Do you mean difficult-to-detect but "obviously" bugs that can lead to UB, like buffer overflows that only happen in rare circumstances (like with unsanitized input)? Or do you mean difficult to detect unexpected "miscompilations" by the compiler based on some UB that is non-obvious to most programmers and/or not well-known?
Because I was referring to the latter, and in my perception most talk about UB is. I haven't seen the latter happen myself, and I haven't read that many horror stories where this actually happened.
For better or worse, I'm not angry with the compiler if I code a logic bug and corruption happens. That's just what I expect.
Maybe if you're indeed saying the latter is a "major cause of security vulnerabilities", could you provide a few examples where it's the language's or compiler's "fault"? I can see that the line is not well defined here of course, because technically it's all just UB - but the distinction really was my point, which I made from a practical perspective.
> Do you mean difficult-to-detect but "obviously" bugs that can lead to UB [...]? Or do you mean difficult to detect [...] UB that is non-obvious to most programmers and/or not well-known?
I meant both, as I wasn't drawing this distinction.
> I haven't read that many horror stories where this actually happened
You may be right that most of the problematic instances of UB are doing something that's clearly not right even to inexperienced programmers, but again I don't see much value in making the distinction. I mentioned the Chromium stats earlier. Those security issues are real. Many of those issues presumably wouldn't happen in a language that prevented UB.
(It's not necessarily the case that all the issues would have been avoided, as it's possible a bug might still have manifested, but in a well-defined way. A UB-invoking memory-management bug might correspond to a failure to reset a data-structure, in a safe language. Only the former invokes UB, but both could have security consequences.)
> For better or worse, I'm not angry with the compiler if I code a logic bug and corruption happens. That's just what I expect.
You expect it because you know the C and C++ languages don't offer robust means to avoid undefined behaviour. This doesn't generalise to other languages.
In C and C++, silent data-corruption can occur if you try to write into an array but go out-of-bounds. That doesn't happen in many other modern languages. Unlike Ada, C doesn't even let you enable robust runtime bounds-checks for your debug builds. (To my knowledge no C compiler is able to offer this feature.)
> Maybe if you're indeed saying the latter is a "major cause of security vulnerabilities", could you provide a few examples where it's the language's or compiler's "fault"?
I wasn't drawing the distinction at all. I'll use an example from the plainly erroneous category.
Use-after-free and double-free errors are both undefined behaviour, in C and in C++. In Safe Rust, they cannot ever arise because of the way the language is defined, so the door is closed on those forms of runtime error. We don't need to talk about blame.
Memory-management issues of this sort are precisely the kinds of issues that affect Chromium. Not even Google can keep undefined behaviour out of their most high-profile C++ codebase. (In fairness though, the codebase would likely be quite different if written from scratch today in modern C++.)
On the not plainly erroneous side: a subtlety that can result in security consequences is the elision of a memset call by an optimising compiler which can result in sensitive data not getting zeroed out before deallocation. This isn't actually UB, but it's a good example of 'language lawyer' trouble with C/C++. [0]
As an aside: I once spotted a competent C++ programmer (vastly more experienced than myself) writing code which applied memcpy to an array of non-POD objects. If you'll forgive a painful mix of metaphors: C++ is large enough that even experienced programmers can have blind spots to its dark corners.
> In C and C++, silent data-corruption can occur if you try to write into an array but go out-of-bounds. That doesn't happen in many other modern languages. Unlike Ada, C doesn't even let you enable robust runtime bounds-checks for your debug builds. (To my knowledge no C compiler is able to offer this feature.)
Valgrind offers bounds checks with malloc() allocations and probably other allocations, and while I don't have extensive experience with valgrind it works surprisingly well. I imagine runtime checks could be made possible for any allocator by offering a slice(ptr, type, count) builtin call. I don't really see the language causing any problems, it's more what compiler output and optimizations we've come to expect.
> Memory-management issues of this sort are precisely the kinds of issues that affect Chromium.
They're just what a C programmer expects. I'm not saying you have to like the outcome but this is not "UB" for me - in the sense that it's been utterly obvious from day 1 that this type of issue can cause corruption (because how would it not?), long before there was any talk about UB.
> As an aside: I once spotted a competent C++ programmer (vastly more experienced than myself) writing code which applied memcpy to an array of non-POD objects. If you'll forgive a painful mix of metaphors: C++ is large enough that even experienced programmers can have blind spots to its dark corners.
I'm not defending C++ (in fact I actively avoid having to deal with it) but I think it's obvious that this sort of code is extremely likely to break.
> Valgrind offers bounds checks with malloc() allocations and probably other allocations
Right, and Valgrind is very impressive, but it's a very intrusive and heavyweight tool, rather than a compiler flag. (I often mention Valgrind by name in these sorts of discussions, [0] we're thinking along the same lines here.)
> I imagine runtime checks could be made possible for any allocator by offering a slice(ptr, type, count) builtin call
It would presumably need 'fat pointers', which have ABI issues.
It would need to cope with statically allocated arrays, heap-allocated arrays, and arrays with automatic lifetime, including VLAs and alloca. It would also need to cope with passing a pointer mid-way into an array (something forbidden in, say, Java).
There would be considerable payoff to solving this problem, but it isn't an easy problem to solve, which is why no compiler does so.
> I don't really see the language causing any problems, it's more what compiler output and optimizations we've come to expect.
No, it's the language. The behaviour of modern optimising compilers is consistent with the way the languages is defined. The way the language is defined, and the categories of undefined behaviour that it permits, are very consequential.
I already gave the example of how arrays work differently in Ada, such that Ada compilers can easily add bounds checks for dev builds, whereas C compilers cannot so you need Valgrind, which few people use. (Well, more properly, arrays work differently in C than in just about every other language.) I could give a dozen other examples of ways C permits you to introduce serious bugs into your codebase which other languages robustly defend against.
Again, many categories of bug simply cannot occur in other safer languages, because of the way safe languages are defined. Use-after-free, double-free, signed integer overflow, read-before-write, divide-by-zero, out-of-bound access, mis-aligned access, data-races. Using a language like Safe Rust closes the door on every one of those kinds of undefined behaviour.
Recall that these are precisely the kinds of errors that result in major security vulnerabilities. This isn't purely academic. Safe languages like Safe Rust (or even plain old Java, although Java has some unsafe corners) stops those issues arising, and that means better security.
Also, as we've discussed, the way C is defined makes it difficult for C compilers to use robust compile-time or even run-time checks to detect undefined behaviour. The result is that major C codebases get delivered with undefined behaviour bugs, which are a common source of major security vulnerabilities.
> I'm not saying you have to like the outcome but this is not "UB" for me - in the sense that it's been utterly obvious from day 1 that this type of issue can cause corruption (because how would it not?), long before there was any talk about UB.
Respectfully there is no such thing as 'UB for me'. It's an accepted technical term-of-art with a clear definition. People do PhDs on this topic. [1]
You're not engaging with the points I've made about how other languages are defined in such a way as to prevent these issues arising. You seem to be focussing on how it's the programmer's fault, which isn't the point at all.
Also, operations which cause data-corruption in C aren't always this way in other languages. In Java, an out-of-bounds write (into an array) results in an exception being thrown, for instance. In verified SPARK Ada, out-of-bounds writes cannot arise in the first place.
> long before there was any talk about UB
Prior to the standardisation of the C language that may have been true in the sense that perhaps the term undefined behaviour had not yet been coined, but that doesn't have any bearing on our discussion. C was always an unsafe language.
> I think it's obvious that this sort of code is extremely likely to break
And yet it didn't occur to the experienced C++ programmer. The whole idea of non-POD types isn't obvious to a C++ programmer who started out with C.
To understand C or C++ well you need to essentially know the language spec. You can't simply learn by doing, as you may easily be tricked into thinking that bad code is correct and robust. It isn't obvious that unsigned integer addition overflows by wrapping whereas signed integer addition overflow causes undefined behaviour.
Google's Chrome team are unable to keep undefined behaviour out of their (necessarily large and complex) C++ codebase. It's unlikely that you're smarter than them. Even if you are, undefined behaviour continues to be a problem for real C/C++ codebases, resulting in a steady stream of security issues.
> Respectfully there is no such thing as 'UB for me'.
Arguing like that and then saying I'm not "engaging with the points you've made" after you've been talking completely aside the points of my OP, well... you're being a bit of a pain in the butt. I totally get your points, so let's agree that we're just looking for different things.
(Btw, a couple of days ago I did try Rust once again for a few hours, intending to convert a simple toy project to it. After a few hours of fighting the compiler, editing boilerplate files, looking for the right crates for basic Win32 interop, waiting for downloads, etc... I quit without making it work. Nothing changed in my feeling that without an extreme (or potentially infinite) investment of energy, C will continue to be more productive for me personally, for what I do - despite all its flaws).
That's half the world? Asia alone is almost entirely either anti or apathetic towards NATO and Western sanctimonious BS, and that's 60% of the world's population.
Baffling you'd assume Africans, who unilaterally despise American and Western colonialism and primarily align with China, would also be on your side.
The fact Americans continue to assume this some great battle between Good vs. Evil is absurd. Russia is fighting for what America took from them - and winning.
NATO invaded multiple Middle Eastern countries for nearly 2 decades for oil. Americans thinking they're the good guys in any way is a joke.
> Asia alone is almost entirely either anti or apathetic towards NATO and Western sanctimonious BS, and that's 60% of the world's population.
There's more to Asia than China, Russia, and North Korea. Taiwan, South Korea, and Japan are not "apathetic toward NATO and Western sanctimonious BS". If they were, they wouldn't allow US military installations in their sovereign territory. Taiwan and South Korea count on "NATO and Western sanctimonious BS" to continue existing (well, South Korea might theoretically be able to defeat North Korea on its own if it were a one-on-one conflict, but in reality it's mostly about US support).
> Russia is fighting for what America took from them - and winning.
America didn't "take" Ukraine from Russia. No Americans were seated at the Belovezh Accords: the Soviets decided to break up themselves. Ukraine has the right as a sovereign nation to make its own decisions.
> NATO invaded multiple Middle Eastern countries for nearly 2 decades for oil.
No, it wasn't for oil, and no, it wasn't "NATO" that invaded Iraq--it was called the "coalition of the willing" specifically to distinguish it from NATO. The Iraq War was a bad idea, but not because NATO wanted oil.
> Baffling you'd assume Africans, who unilaterally despise American and Western colonialism and primarily align with China, would also be on your side.
Yes, but this doesn't mean that they'd therefore side with Russia attempting to reinstate a colonialist empire. That really, really doesn't make sense (and indeed, everything coming from Africa has been condemnation of Russia's invasion).
And keep in mind that China seems to not really be a fan of Russia's aggression here, while they really dislike NATO, they seem to be signaling that they didn't expect an invasion of the scale that happened, and would have preferred less. I mean China is participating, to a limited extent, in sanctions against Russia.
1) You don't fight an army the same way you protest your government. Yes there was gunfire, fighting and massacre during Euromaidan, but fighting riot police (most of whom were not shooting the protestors with live ammunition) is nothing like fighting an army that's coming in with assault rifles, tanks, apcs, air strikes, etc.
2) That's a massive accomplishment by the armed forces of Ukraine, but it is still useful to advise civilians and make them better prepared in case the fight gets to that point. They weren't handing out assault rifles to civilians for the lulz. I'm sure there are a lot of people among them who have no fighting experience.
I can't verify the claim that r/youtube was deleting reports but having regularly used ceddit, I wouldn't be surprised.
However, there's no need for me to argue about the first sentence. Please take a look at https://www.reddit.com/r/youtube/ and it is literally filled with reports of account bans from the past few hours. 95% of the hot stories. You look in the comments, you find dozens more.
Saving screenshots for posterity (those termination/strike threads on r/youtube are all relevant): https://imgur.com/a/ekqk3B7
I think it's the right call, given that they have a problem with Russian saboteurs who snuck into the country before the war started. They're currently discouraging the use of the Russian language (many Ukrainians speak both Ukrainian and Russian) to avoid suspicion. Tension is extremely high right now, checkpoints everywhere around Kyiv, guards on the edge, and there's a huge risk of escalation if you're suspected of being on the wrong side.
There's been many videos of alleged saboteurs getting arrested, and the rumor is that your ability to pronounce a Ukrainian word correctly is used as a test to find out where you're from.