I remember back in the day when Google+ was just launched. And it had promoted content. Content not from my 'circles' but random other content. I walked out and never looked back.
Of course, Facebook started doing the same.
The thing is, anything from people not explicitly subscribed to should be considered advertorial and the platform should be responsible for all of that content.
In general it would help if you would spend some text on describing what features of C99 are missing in other languages. Giving some code and assume that the reader will figure it out is not very effective.
As far as I can tell, Rust can do what it is in your example (which different syntax of course) except for this particular way of initializing an array.
To me, that seems like a pretty minor syntax issue to that could be added to Rust if there would be a lot of demand for initializing arrays this way.
E.g. notice how here in Rust each nested struct needs a type annotation, even though the compiler could trivially infer the type. Rust also cannot initialize arrays with random access directly, it needs to go through an expression block. Finally Rust requires `..Default::default()`:
I don't have C++ code around, but compared to C99 it has the following restrictions:
- designators must appear in order (a no-go for any non-trivial struct)
- cannot chain designators (e.g. `.a.b.c = 123`)
- doesn't have the random array access syntax via `[index]`
> ...like a pretty minor syntax issue...
...sure, each language only has a handful minor syntax issues, but these papercuts add up to a lot of syntax noise to sift through when compared to the equivalent C99 code.
In Rust you can do "fn new(field: Field) -> Self { Self { field } )"
This is in my experience the most common case of initializers in Rust.
You don't mention one of the features of the Rust syntax, that you only have to specify the field name when you have a variable with the same name. In my experience, that reduces clutter a lot.
I have to admit, the ..Default::default() syntax is pretty ugly.
In theory Rust could do "let x: Foo = _ { field }" and "Foo { field: _ { bar: 1 } }". That doesn't even change the syntax. Its just whether enough people care.
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.
Yes, there is nothing like 'nuclear war without nukes' that is happening here. And I was trying to demonstrate that your logic seem to lead to conclusion that the 'nuclear war without nukes' started in 2014.
My argument is that you can't bring strategic defeat without leveling cities or utterly destroying the power generation and electric grid. And that's not what is happening in the Ukraine or even Belgorod for that matter
In this war strategic victory is not the destruction of the state, but the control over development trajectory of the rival for the foreseeable future. Russian objective is and was not to annex entire Ukraine, but to ensure that it does not become menacing part of NATO infrastructure (they are surprisingly content with Ukraine joining EU). This is political goal and thus can be pursued through hybrid warfare, which includes psychological pressure on Ukrainian population, to ensure that current administration will loose political support and will be pressured into a peace deal on terms favorable for Russia. Ukraine does the same to achieve the opposite goal, but of course with much less success.
The whole story with territorial question is part of this: possible peace settlement could include just splitting Donbas region on the current front line, so that Putin could claim victory and Ukraine could just say they did what they could. But Russia wants more, they need Donbas in original borders, which is unacceptable to Ukraine. Why? Because if this question will be settled in the peace deal, it may open Ukraine eventually path to NATO. They want to create permanent tension the same way as it happened to Georgia, deferring the final settlement by a hundred years (see Taiwan as an example, which occupies China for decades).
>In this war strategic victory is not the destruction of the state, but the control over development trajectory of the rival for the foreseeable future.
No, it wouldn't be victory, it would be compromise. And the Ukraine isn't Russia's rival, it's just cannon fodder for the West.
>they are surprisingly content with Ukraine joining EU
Kremlin says that. Doesn't have to be true.
>which is unacceptable to Ukraine
Why is it unacceptable to the Ukraine?
I see why it's unacceptable for current regime in Kiev because they can't just say "we actually don't need Donbass, never mind hundreds of thousands lives we wasted defending it".
> 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.
The EU as a whole is rich enough, the problem is that its the elites that are rich, not the ordinary citizens. However, the burden of support (via taxes and cutting welfare) will be places on ordinary citizens. Hence, the need to flame the war rhetoric. Still, there is no real support for forever war among EU citizenry.
Even if there is enough support for economic/material support of Ukraine, the matter of sending your man to die on the eastern front is an altogether different matter. Even Poland is not willing to do that. I mean, 'I am afraid of dying in a war, so I better go die in a war, to prevent that.'
> 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.
Of course, Facebook started doing the same.
The thing is, anything from people not explicitly subscribed to should be considered advertorial and the platform should be responsible for all of that content.
reply