Russia's military force currently relies on men willing to die for money. That could change. But Putin seems reluctant to force the general population to die in Ukraine.
Classic economic theory suggests that the amount you need offer to people willing to die goes up over time.
For Ukraine the main thing is to get to the point that Russia doesn't attack any more. There is no need for Ukraine to concur any part of Russia. Even getting the currently occupied land back is mostly optional.
This war has already changed. Near-stalemate on the front lines, exchange of strikes on civilian infrastructure (Ukraine made to Belgorod what Russia made to Kiev). It‘s a nuclear war without nukes, aiming at strategic defeat without advancing armies. And Russia definitely has more resources for it.
A few days ago Ukraine knocked out central heating infrastructure in Belgorod, a regional capital with 350k people, which is unlikely to be repaired until spring. Two civilians repairing it from previous strikes were killed. Whether this is rare or not, it doesn’t change anything about what I said about changing character of the war: both sides largely gave up on trying to win on the battlefield and now attack energy infrastructure of each other, putting pressure on civilian population.
When you knock out primary energy source in a large city instead of attacking military consumers, it has one goal - terror. Most people suffering from it will be civilians. There will likely be deaths. Look at the recent terrorist attack in Berlin by far left extremists: blackout of a single district resulted in at least one known direct casualty. How many people will die of hypothermia or inability to get help being locked in a high rise residential building? This is happening now in many places in Ukraine as well as in border regions of Russia. I do think it’s the same as targeting civilians directly.
>When you knock out primary energy source in a large city instead of attacking military consumers, it has one goal - terror.
Not if that city's industry is contributing to the war effort.
>Most people suffering from it will be civilians. There will likely be deaths.
You can say that about Western sanctions on Russia too. How many people have died because of a single MRI scanner or cancer drug that couldn't be bought by a Russian hospital?
Was it the "nuclear war without nukes" since the day the West imposed blanket sanctions on Russian economy?
Or did that "nuclear war without nukes" started in 2014-2015 when the Ukraine cut electricity and water supply to Crimea? "It has one goal - terror", right?
I really don’t understand your point. Are you questioning the choice of metaphor?
Ukraine cutting supply of electricity and water to Crimea did demonstrate the attitude of the Ukrainian government to people it considered once their citizen. It obviously wasn’t a part of the current chapter of the war.
> Even getting the currently occupied land back is mostly optional.
That's only true in the short term.
If Russia gets out of the war with Ukraine with territory gains, that only serves as incentive to start up again after Russia can regroup. After all, Putin's stated long-term goal is to take the entire country (among others) and restore the USSR.
Of course, taking back the occupied land is also easier said than done, as it would severely weaken Putin domestically to have expended all these resources and lives for nothing. There's no way he can allow that.
There is the issue that Russia tends to attack weak countries. The Baltic countries are small and also something Russia would like to have. But part of NATO.
Ukraine was seen as easy to take over. But that was clearly a wrong assessment.
> "I have said many times that the Russian and Ukrainian people are one nation, in fact. In this sense, all of Ukraine is ours [...] But you know we have an old parable, an old rule: wherever a Russian soldier steps, it is ours."
Also, looking at Russian track record specifically, is Georgia, which was militarily defeated in 2008, part of Russia? Did they formally annex Abkhazia or Transnistria? Does Lukashenko report to Putin?
The EU is rich enough to support Ukraine for a very long time. During that time it is likely that Ukraine develops better and better weapons. This requires Russian army to improve as well.
It's not clear how the Russian army will improve when the economy declines.
The EU is rich enough but will they stay "willing enough"? Unfortunately, many EU parties that are gaining popularity are also against spending money on Ukraine
The EU, well NATO has the problem what Russia will do when it is no longer at war with Ukraine. There is also the question what the US would if Russia attacks a NATO country.
So European NATO countries basically need to keep supporting Ukraine while they try to becomes militarily independent of the US.
EU just needs to support Ukraine until Russia has dug themselves into a hole that will take generations to recover from. Their might be a point where the war hasn't ended but Russia is no longer seen as a threat by the EU.
One issue is that Europe got caught with it pants down. It likely that Europe will keep improving its defense long after it is no long necessary from an economic point of view. Supporting Ukraine in destroying whatever Russia manages to produce is a sound strategy in this context.
If Russia really becomes weaker and the war winds down a bit, then supporting Ukraine is likely to become cheaper as well. But as long as Russia manages to send tons of drones and missiles to Ukraine, Europe should be worried. So Ukraine will remain a testing ground for air defense for a while.
There is also the issue with the Baltic countries and to some extent Finland. Those countries are terrified that Russia will do something stupid.
> Converting between ACK and GCC assembler is a solved problem.
I assume you mean because the assembler was manually migrated in later Minix versions, not because there is a tool which can do so automatically. Or did I miss this?
> and a lot of interesting stuff was left out
Can you please make examples what you mean specifically?
Yes, there is a tool called asmconv, that converts.
One example is the new compiler driver that can use ACK and GCC from a single compiler driver and that can automatically convert assembler and figure out which archiver to use to create libraries.
Another example is library support for filenames longer than 14 characters that was completely transparent. MINIX3 just broken all backward compatibility by increasing the size of directory entries to a new fixed size.
I'm sure there is more stuff, these are just a few I remember.
Yes. Absence of direct control by the government. The VU was founded for religious reasons, so the main goal was to be able to teach theology according to the particular type of protestant Christianity that the founders of the VU believed in.
Selling ACK meant money for research into distributed systems (Amoeba) and parallel programming languages. I can see that money for research is more attractive than open source.
For MINIX the situation was different and I think more unfortunate. AST wanted to make sure that everybody could obtain MINIX and made his publisher agree to distributing the MINIX sources and binaries on floppies. Not something the publisher really wanted, they want to sell AST's book. In return the publisher got (as is usual for books) the exclusive right to distribute MINIX.
Right at the start that was fine, but when Usenet and the Internet took off, that became quite painful. People trying to maintain and distribute patch sets.
I disagreed strongly with that at the time and still do. The money we're talking about here was a pittance compared to the money already contributed by Dutch society to the university where these people were working. Besides that some of these royalty streams went into private pockets.
A friend of mine was studying under Andy and I had a chat with him about this at his Amstelveen residence prior to the release. He was dead set on doing it that way. As a non-student and relatively poor programmer I pointed out to him that his chosen strategy would make Minix effectively unaffordable to me in spite of his stated goal of 'unlocking unix'. So I ended up in Torvald's camp when he released Linux as FOSS (I never contributed to either, but I figured as a user I should pick the one that would win the race, even if from a tech perspective I agreed more with Tanenbaum than with Torvalds).
Minix was (is?) flogged to students of VU for much longer than was beneficial to those students, all that time and effort (many 100's of man years by now) could have gone into structurally improving Linux. But that would have required admitting a mistake.
Universities get paid for teaching and research. Any software that is produced is a by product. Producing production quality software in a university is not easy and the university has to find a way to fund it.
MINIX was originally a private project of ast. It worked very well for the goal of teaching student the basics of operating systems.
One thing that might have been a waste of time is making the MINIX utilities POSIX compliant. Then again, many students would like an opportunity to work on something like that. The ones that wanted to work on Linux could just do that. Students worked in their free time on lots of interesting projects that were unrelated to the university.
> The ones that wanted to work on Linux could just do that.
Sure, but time is a very finite quantity and wasting a couple of years on Tanenbaum's pet project may have resulted in some residual knowledge about how operating systems in general worked but looking at most of the developments they pursued the bulk were such dead-ends that even outside of VU there was relatively little adoption. The world had moved to Linux and VU refused to move with it.
I wonder who you are thinking of who 'wasted a couple of years'. Regular students do one course in operating systems. That is a series of lectures and some practical work. The practical work is a couple of weeks at most if you know what you are doing.
Some people spent a lot more time on MINIX, but that was either as a hobby or the PhD students who worked on MINIX3. But MINIX3 generated lots of papers with a best paper award, so that can hardly be seen as wasted from an academic point of view.
I have some friends that went that route. They did not come away with anything that helped their careers later on and the 'academic point of view' in CS in NL hasn't been the best way to put food on your table since the days of Dijkstra.
The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language.
This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code.
I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.
The problem is not so much "when unsafe code gets called indirectly by safe code", which is fine if the unsafe happens to be sound. The problem is that "when C-like or Zig-like unsafe code wants to call safe code", the safe code is running in a context where its implied invariants may be violated, leading to insta-UB. Hence code that's intended to provide "library-like" facilities to unsafe blocks cannot be idiomatic Safe Rust, and it needs to be written even more carefully.
For instance, any &mut reference in Rust is assumed not to be aliased, and any &reference not involving UnsafeCell<...> is assumed not to be written to. These implied contracts can be loosened, e.g. by using &Cell<> if applicable (may alias, can be read or written safely, but only "as a whole object": access to the internals does not escape beyond any single operation) which is arguably closer to idiomatic C.
MaybeUninit<> is another common example: C and Zig code often works with possibly-uninitialized data, but this possibility has to be accounted for explicitly in a safe Rust interface. It's always insta-UB if a safe Rust function is passed uninitialized data, even when the equivalent would work idiomatically in C.
This is what makes Rust Rust and I'd say what makes Rust popular. The way safe Rust is safe. Of course this comes at the expense of making writing unsafe a lot harder.
Though I can imagine that unsafe Rust still has to many of the safe Rust's rules. So there could be a better unsafe language that has fewer restrictions.
The real sticking point is not whether there could be a better unsafe language, but a better unsafe library (or unsafe-friendly library that's still conditionally safe in some rigorous sense). That's a much closer goal that could even be achieved within Rust itself as it currently exists today.
Typically, MUST means that if you don't do that then something will break at the protocol level.
SHOULD means that if you don't that, bad things are likely to happen, but it will not immediately break at the protocol level and during discussion in the IETF some people thought there could be valid reasons to violate the SHOULD.
Typically, IETF standards track RFCs consider the immediate effects of the protocol but often do not consider operational reality very well.
Sometimes operational reality is that a MUST gets violated because the standard is just wrong. Sometimes a SHOULD becomes required, etc.
Certainly for email, there is a lot you have to do to get your email accepted that is not spelled out in the RFCs.
Maybe because the performance gain is just not there. Adding support for string with explicit length everywhere is a huge amount of work. And then the question is whether such a string is like a Rust slice or something else.
And then the gain is close to zero because most filenames are short enough that there is almost no gain.
You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename.
You can't just toss a contiguous number of bytes you to convert it first.
Every single piece of software that need to interact with the file system needs to deal with this.
I'm not asking about a new string type. I'm asking to be able to be free from null terminating string.
In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.
Even when you don't care about being cross-platform, you still need to rely on specific routines instead of having the most low level `ut8fopen(buffer, len, mode);`
My point is that I wish we would have a new "standard OS-related API", not even talking about introducing span type or anything, just creating something way more sane and care about moving forward from this point.
If I was about to create my own OS and decided to eliminate null-terminating string, and keep it as tiny and efficient as possible, I would face so many issues because I cannot reuse 99% of the code (related to file API) that already exists, I would need to think how to properly parse arguments from "main" without overhead etc.
The thing for me at least is that when I looked at Pascal, MODULA-2, Ada, if you had complex data structures which had to allocate and deallocate memory, then those language would not help at all. They would allow you to make pointer mistakes. Pascal and MODULA-2 were also very restrictive in various area (no generics). Ada is better in that respect, but Ada compilers were rare.
In my opinion it is only Rust that offers a language without runtime system requirement and fixes essentially all of the problems of C.
First of all C did not had any generics, so same playing field.
C has a runtime, even if tiny. That is what calls into main(), handles floating point arithmetic when none is available, functions that run before and after main(), nowadays also does threading.
Heap memory handling in Pascal, Modula-2, Ada, is much safer than C, first of all no need to do math to calculate the right size, arenas are available on the standard library, dinamic allocation can also be managed by the compiler if desired (Ada), pointers are safe as they by default must be used with existing data, however if one really wants to do pointer arithmetic it is available.
The only issue that they have in regards to C, is the use-after-free, but that apparently isn't an issue for folks moving away from C into Zig, wich is basically Modula-2 with some C syntax flavour.
C uses pointer casts all over the place to fake generics. If you don't have that (in Pascal or MODULA-2) then life becomes very unpleasant.
There is a quite a bit of C code that makes creative use of the size of allocations. For example linked lists with a variable sized payload. Again one of the things that would prevent a C programmer from switching to Pascal.
I don't expect the Zig user base to become larger than the Rust user base any time soon. But we have to wait and see, Zig is quite young.
> C uses pointer casts all over the place to fake generics.
by "C" do you mean users of C? because most of the C code I write I don't use those sorts of techniques; instead I just use the preprocessor to make scuffed generics.[1] Unless you mean in libc itself, where I don't recall any use of pointer casts like that? If I'm missing something, please enlighten me.
Same tricks are possible in Modula-2, Pascal, Ada, if fake generics count.
Creative use of the size of allocations are also possible in those languages, the BIG difference is that they aren't the default way everything gets done.
In Pascal (not the original Pascal standard, but, say, Turbo Pascal), could you allocate a variable-sized array of something, and still have index protection when using it?
(I know quite well that C couldn't. Even a C++ vector may or may not, depending on which access method you use.)
Classic economic theory suggests that the amount you need offer to people willing to die goes up over time.
For Ukraine the main thing is to get to the point that Russia doesn't attack any more. There is no need for Ukraine to concur any part of Russia. Even getting the currently occupied land back is mostly optional.
reply