yeputons

I've heard so. I think my first DB train was around 2019, it was another ICE from Berlin to Munich. They've changed the train, cancelled all seat reservations as a consequence, delayed it for a few hours, I missed my connection in Munich... Maybe I'm unlucky :) E.g. I'm quite lucky with London trains (never had a cancellation/significant delay), but I've heard Cambridge residents would love to have a word with me.

Moreover, I've never heard of a long-distance passenger train being delayed or cancelled in Russia. Granted, I mostly knew about major trains to major destinations from Moscow/Saint Petersburg. Not a single person I knew had a plan for "the train is cancelled/delayed". Like, forgetting ID is more likely. I've heard it's a USSR legacy where passenger trains had much higher priority than even freight trains. Flight cancellations or delays - sure, they do happen.

Local trains even in these major cities do get delayed (around 2-5 minutes is typical, very rarely up to 30 minutes) or cancelled. Delays are in the moment, cancellations are typically announced a day or two in advance, as I was told.

"11 trains are late for at least two hours" makes regional news.

The map claims a journey from Berlin to Bremen takes 2h57m. My last one took 6h 33m. And it was only a single connection in Hamburg. The Berlin-Hamburg ICE got stuck for a few hours in the middle of nowhere, then a few trains from Hamburg to Bremen got cancelled... The usual stuff.

>How is it possible that I can write efficient and provably-safe code in C# without a degree in type theory?

Because of two things mentioned in the article just below.

> Here we see C#’s first trade-off: lifetimes are less explicit, but also less powerful.

If C# is less powerful, it does not need powerful syntax. One does not need explicit lifetimes in Rust for a long time either, deduction work just fine.

> The escape hatch: garbage collection

If C# is ok with not tracking _all_ lifetimes _exactly_, it does not need powerful syntax. Not an option in Rust, by design.

Basically, not all code is possible to write, and not all code is as efficient.

As a neighboring comment mentioned, at least one banned individual seems to be based in the US is employed by Amazon, as per their LinkedIn, including some old posts: https://news.ycombinator.com/item?id=41933300

They just happened to still use their older .ru email in the MAINTAINERS file.

That's a good example. Thank you.

> In US.. well it depends but you could quite easily bring down the people doing this to you with yourself

I personally don't see much difference between "going down" and "going down together with other people". At least for myself and my family. I'm screwed anyway.

Do you have any example of a removed person with .ru email who lives and works in the US?

I saw some comments on Reddit about people with @gmail.com (I think), but other comments pointed out that these people were not actually removed and were just present on a screenshot.

For those confused: GitHub has comments for commits, and some are piling up for this particular Linux kernel mirror.

Well, we have a response from Linus himself, in his usual style: https://lore.kernel.org/all/CAHk-=whNGNVnYHHSXUAsWds_MoZ-iEg...

Not much exact reasoning added, if you ask me. Quoting:

> Ok, lots of Russian trolls out and about.

> It's entirely clear why the change was done, it's not getting reverted, ...

> And FYI for the actual innocent bystanders who aren't troll farm accounts - the "various compliance requirements" are not just a US thing.

> If you haven't heard of Russian sanctions yet, ...

> As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. ...

I'm not a lawyer, but I don't think so. For example, there is no penalty for not having an accountant on payroll. But there are some for not keeping adequate records. I suspect it's irrelevant whether you have a full-time accountant so your records are always in order, or if you do nothing all year and hire someone for a big overhaul each December and also every time authorities need something.

Either country can also say: "we have this law that requires people to help law enforcement agencies to implement backdoo^W special technical measures to advance national security interests, and also a gag order because it's a matter of national security".

I think Australia had something called Technical Capability Notices (TCNs) back in 2018? For legal entities for sure, not sure about hobbyists.

The last paragraph also makes the whole situation sound like someone cares for Russian developers' well-being. I highly doubt it was ever the intention.

I think it's more likely that everyone will forget in a few days and we will never know. Maybe there will be few more random bans.

I highly doubt anyone banned will even try to send "sufficient documentation". The wording is as vague and arbitrary as it gets, and the underlying tone sounds to me not like "we have such and such requirements", but like "some Russian-sounding names are banned, but we still have to demonstrate there is a due process".

Reminds me of banks. Banks are fined for not having processes for detecting money laundering. Not money laundering, mind it, just having "inadequate" processes. If such a process flags someone, that someone is blocked and they should provide "sufficient documents", but the bank is not allowed to tell them why or what, that would be "tipping off", which is illegal. And then it all comes down to bank's internal policies (that the bank is not allowed to disclose) or even a personal relationship with a branch manager.

That would be a nice explanation, but some people with @gmail.com were also removed from the list.

Would you mind sharing a link? For me it was Steven Mould's: https://www.youtube.com/watch?v=FMRi6pNAoag

It seems to me that C and Rust approach library APIs with different mindsets.

Warning: lots of stereotypes follow.

Rust believes APIs should be [close to] impossible to use incorrectly. So we get rich type system, contracts, and other kinds documentation. All corner cases are either impossible because of the type or explicitly written down in the contract. If UB happens because user wrote incorrect code, that's a library's bug because it did not defend against it.

C believes the programmer. Documentation typically mentions happy path and some popular errors only. Lots of assumptions are implicit, like thread-safety, reentrance, (lack of) NULLs, lifetimes of inputs/outputs. It's up to the user of the library to figure out restrictions if their usecase is not in the documentation. Common sense and knowledge of C traditions helps. If UB happens because the user did something a bit out of the usual, it's on the user.

That brings us to different mindsets of library developers.

In Rust you typically write code while proving that it's correct in all theoretically possible cases, otherwise the code does not even compile. If it becomes too hard, you refactor API, possibly making the implementation harder. But your API is kind of nice in the kind.

In C you take whatever piece of code you found to be useful, extract it in a function or two and use in the project. If you happen to need that exact code somewhere else, you use it. There is no need to prove that the code always works or that it's a sound abstraction. If it works, it works. If it stops working in some case because of a bad API design, then you decide whether it's worth refactoring or not. That makes the initial implementation simpler, but it lacks contracts by design.

So I attribute it to cultural differences between "C programmers" and "Rust programmers". For Rust programmers, "full function contract" is a must, so documenting it seems easy. For C programmers, "full function contract" is not required for writing working code in 95% of cases, so documenting it is extra chore with no benefit.

Fun fact: execution is not only deterministic, but guaranteed to terminate eventually. I.e. no indefinite loops or recursion is allowed. Quite useful for a configuration language. Of course, that means it's not Turing-complete.

I suspect it's either just an SQL expression sent to the DB, or it's `eval`ed in Python.

Does installation matter at all? Once you've installed a package, you're very likely to immediately include it in the project, build, and run. Any malicious code can easily run during the package's initialization in your app.

Seems like prohibiting arbitrary code in installation scripts would only help with issues like Bumblebee's `rm -rf`: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

> A utf character from a language that has zero chance of being mapped to your programmer's keyboard in the middle of a code line, that would be obvious intentional tampering or at the very least raise some eyebrows.

I accidentally get Cyrillic "с" in my code few times a year. It's on the same key as Latin "c", so if I switch keyboard layout, I don't notice until the compiler warns me. Easy to do if I switch between chats and coding. Now my habit is to always type a few characters in addition to "c" to check what layout I'm _really_ using.

Granted, it's easier with a one-letter variable called "c", but with longer names I can easily see myself not typing "c" the first time (e.g. not pressing hard enough), starting build, chatting in some windows, getting back, facepalming, "fixing" the error by adding "c" or "с" depending on my keyboard layout.

My main issue with any virtual camera-based screensharing is that Zoom (and others) seem to degrade camera first, screensharing second, audio last. If I share a static image, it'll eventually get through. Internet lagging, laptop lagging, some random updater running, whatever.

But if I share everything via a single "camera" channel, it's all or nothing. The only "in between" is "image is blurry, face is barely legible, text is illegible".

Would you mind linking to PhpStorm community edition? I don't remember being one. I believe only IntelliJ and PyCharm come with a free version, and the rest (CLion, RubyMine, PhpStorm, WebStorm, GoLand) do not.

I recommend "Software Foundations" by Pierce and others https://softwarefoundations.cis.upenn.edu/ if you're a programming fan.

If you're also into math, it's a beauty in itself (Godel's incompleteness theorem, quantifier elimination for logic formulas about complex numbers). I think there should be a good book on math logic somewhere, but I'm not familiar with books in English.

Hudson River Trading has just release an MIT License header-only structured concurrency library for C++20 coroutines. Including example bindings to Boost.Asio and Qt.

Here is a full article of such examples: https://manishearth.github.io/blog/2017/01/14/stop-ascribing...

Discussion on HN: https://news.ycombinator.com/item?id=31858311

Yes, I think it heavily depends on what you're doing and your mindset.

E.g. if you work with a single compiler on a single platform all the time and expect the compiler to "just compile the code", then you're likely to learn all its quirks, avoid them automatically, use proper abstractions/contracts/invariants to guard against incorrect code, etc. Moreover, you likely know how exactly the most popular UB shows itself with your compiler.

If you juggle compilers all the time and work with not-so-high-quality code (legacy or not), especially the one with little tests, I expect UB to pop up a lot. Or even if you just test on one platform and do final runs on another, that happens all the time in competitive programming or home assignment grading, especially with beginners.

It should. Everything is copied and by-value, there are no references/pointers or even closures, cycles are impossible. Think Pascal that has garbage collection for strings and dynamic arrays.

My main advice: never trust C, C++, or their compilers. Undefined behavior bites. Even if you just care about the latest 64-bit Ubuntu Linux LTS, compiler updates or flag changes bite as well.

That's the main difference between C and C++ and almost any other language. Not the syntax, neither the perceived "low-levelness", nor manual memory management. In any other language, if you make a mistake, the program behaves badly, but in a predictable way. In C and C++ it may behave reasonably, it may crash in another file altogether few seconds after the erroneous line is executed, it may produce the correct answer. Or it may crash only sometimes. Or it may silently produce an incorrect answer. Different behaviors on different systems, and even on the same system with different compiler flags (e.g. optimization level), of course.

That makes reliable experiments with C and C++ impossible. Even if you have just five lines of code, you almost never know if they're valid C or C++ for sure (separately, whether they do what you want with modern/legacy compilers). It's still fun and everything (congrats on making your own language, that should've been fun!), but you never truly know whether what you wrote is not going to break in a few years (or months) with zero code modifications just because there was another UB lurking around.

See https://evan.nemerson.com/2021/05/04/portability-is-reliabil... if you're curious about more practical implications.

Chat lags for 5-120 seconds depending on livestream settings, writing is much slower than speaking, does not always convey the question as well as sound, and is close to impossible to do on the go.

> Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements.

I'm slightly suspicious this won't work in any way, but I'm not exactly sure why... Maybe because "will be required" is a huge non-technical issue that has to be resolved separately in non-technical means.