JetBrains is and has always been a Czech (and, thus, EU) company, not a Russian one. Yes, the founders are Russian, but that does not make the company so. They did have Russian offices, but closed them after the start of the Ukraine war [1].
The only confirmed link to the SolarWinds attack seems to be that SolarWinds was using TeamCity (JetBrains' CI/CD product) and that this was alledgedly used as a "gateway" to SolarWinds' systems - which doesn't require any cooperation from JetBrains, just an unpatched security issue. In fact, a patch by JetBrains for the exploited issue seems to have been available, but was not installed [2].
So while any company deserves scrutiny, these particular allegations against JetBrains smell like FUD to me.
The company was registered in Prague for political and financial reasons, but it has always been Russian to the core. Yes, they had multiple offices outside of Russia, but they were still mostly populated by relocated Russians. That's why their product quality significantly dropped since 2022, as they've cut themselves from their main source of engineers.
What you linked to is WASI-libc, which is a C standard library implementation on top of WASI - which itself is more low-level and less POSIX-like. https://github.com/WebAssembly/WASI
Fortunately the idea of WASI is for it to be modular. It makes sense for them to have the APIs required to make porting existing POSIX-ish-compatible apps easy, but there are also WASI modules (I forget the proper name) in the works for much more general IO objects etc. that better abstract away the underlying OS if you're willing to invest in that.
So I guess you could summarise it as: backward compatible-ish first, and then figuring out what a neater, more idiomatic world would look like second.
It's a pragmatic approach to bootstrapping the ecosystem, and there's no need for the POSIX-alike parts to hold anyone back, at least long term. Pretty soon you will be able to write apps that target WASI that end up reading and writing files in practice without the app even knowing what a "file" is (the runtime can just hand it an abstract IO object). That's a step beyond just not knowing about things like symlinks, and seems to me like a more "web-flavoured" future that can work even for CLI/desktop apps.
This point was recognized quite early. there is an influential article by Jack W. Reeves from 1992 [1] that looks at the manufacturing analogy and argues that "the code is the design" whereas the "manufacturing" is just the compilation and packaging (that is, super cheap and automated). I believe it‘s this line of thinking that inspired Agile practices, where software developers are seen as engineers rather than code monkeys.
To be clear, the difference is that an URI generally only allows you to refer to a resource ("Identifier"), whereas an URL also tells you where to find and access it ("Locator").
For instance, `https://example.com/foo` tells you that the resource can be accessed via the HTTPS protocol, at the server with the hostname example.com (on port 443), by asking it for the path `/foo`. It is hence an URL. On the other hand, `isbn:123456789012` precisely identifies a specific book, but gives you no information about how to locate it. Thus, it is just an URI, not an URL. (Every URL is also an URI, though.)
I started this to share various learnings from my dev work, as well thoughts on software engineering and architecture. The current two posts are on Redux, but I plan to publish posts on other topics (Kafka Streams, architecture, etc.) soon.
I recommend „Capital in the 21st Century“ by Thomas Pikkety, an economist who has deeply studied wealth and income equality using historical data spanning three centuries. This book has all the evidence you need.
Spoiler alert: income from wealth is on its way of becoming close to being as concentrated as it was in the 19th century (especially in the US), and the share of income from work in total national income is decreasing almost anywhere. So yes, increasingly you can only accrue significant wealth by already having significant wealth.
The only confirmed link to the SolarWinds attack seems to be that SolarWinds was using TeamCity (JetBrains' CI/CD product) and that this was alledgedly used as a "gateway" to SolarWinds' systems - which doesn't require any cooperation from JetBrains, just an unpatched security issue. In fact, a patch by JetBrains for the exploited issue seems to have been available, but was not installed [2].
So while any company deserves scrutiny, these particular allegations against JetBrains smell like FUD to me.
See also JetBrains' own statements on the SolarWinds thing: https://blog.jetbrains.com/blog/2021/01/06/statement-on-the-...
[1]: https://en.wikipedia.org/wiki/JetBrains
[2]: https://www.cisa.gov/news-events/cybersecurity-advisories/aa...