phicoh

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.

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, 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.

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.

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.

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.

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.

Converting between ACK and GCC assembler is a solved problem. Minix-vmd can be compiled with both ACK and GCC.

Unfortunately, when MINIX3 as started, it was copied directly from MINIX2 and a lot of interesting stuff was left out.

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.

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 librarated part means free from government control. Until the VU all Dutch universities belonged (indirectly) to the Dutch government.

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.

ACK used to be self-hosting. Of course, standard Unix utilities like sh and make are required. I still use one of those versions.

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 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.

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.

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.

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.

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.

I wonder if a few people going beyond what is reasonable, is representative of open source projects.

For a lot of open source projects, if you have a normal day job and spend a few hours per week on a project, then the project just never gets very big. It exists, may have a few users. But on a larger scale, nobody knows it exists.

The exceptions are projects where developers spend a lot of time on the project at the expense of a day job. Though there is the possibility that they may have a hard time having a day job in the first place, which may have let to the situation with the open source project.

In general, I think we do have a culture problem where we think projects need to be successful. And people working on a project 'need' to support users (who in general don't pay).

And that expectation of free work happens throughout the open source ecosystem as well. Distributions expect projects to fix bugs for free. Open source projects expect libraries and compilers to be maintained.

Ultimately, change has to come from people who refuse to work for free. Doing something as a hobby for free is perfectly fine. As long as it stays within the scope of a hobby project.

There have always been young people who can quickly hack something together with whatever new tools are available. That way of working never lasts, but the tools do last.

When tools prove their worth, they get taken into to normal way software is produced. Older people start using them, because they see the benefit.

The key thing about software production is that it is a discussion among humans. The computer is there to help. During a review, nobody is going to look at what assembly a compiler produces (with some exceptions of course).

When new tools arrive, we have to be able to blindly trust them to be correct. They have to produce reproducible output. And when they do, the input to those tools can become part of the conversation among humans.

(I'm ignoring editors and IDEs here for the moment, because they don't have much effect on design, they just make coding a bit easier).

In the past, some tools have been introduced, got hyped, and faded into obscurity again. Not all tools are successful, time will tell.

I'm curious about the economic aspects of this. If only experts can use such tools effectively, how big will the total market be and does that warrant the investments?

For companies, if these tools make experts even more special, then experts may get more power certainly when it comes to salary.

So the productively benefits of AI have to be pretty high to overcome this. Does AI make an expert twice as productive?

We recently got a PR from somebody adding a new feature and the person said he doesn't know $LANG but used AI.

The problem is, that code would require a massive amount of cleanup. I took a brief look and some code was in the wrong place. There were coding style issues, etc.

In my experience, the easy part is getting something that works for 99%. The hard part is getting the architecture right, all of the interfaces and making sure there are no corner cases that get the wrong results.

I'm sure AI can easily get to the 99%, but does it help with the rest?

The problem I see is not so much in how you generate the code. It is about how to maintain the code. If you check in the AI generated code unchanged then do you start changing that code by hand later? Do you trust that in the future AI can fix bugs in your code. Or do you clean up the AI generated code first?

I'm not sure what you are talking about. Our software has a stub resolver that is not the one in glibc. It directly issues DNS requests without going through /etc/nsswitch.conf.

It would have been fine if it was getaddrinfo (and it was done properly) because getaddrinfo gives back a socket and that can add the scope ID to the IPv6 link local address. In DNS there is no scope ID, so it will never work in Linux (it would work on Windows, but that's a different story).

It's not a trade-off. Use of /etc/resolv.conf and port 53 is defined by historical use and by a large number of IETF RFC.

When you violate those, it is broken.

That's why systemd has such a bad reputation. Systemd almost always breaks existing use in unexpected ways. And in the case of DNS, it is a clearly defined protocol, which systemd-resolved breaks. Which you claim is a 'tradeoff'.

When a project ships an optional component that is broken, it is still a broken component.

The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.

If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.

It is a bit of a bummer if you spend quite a bit of time tracking down a very weird DNS bug and it turns out to be systemd-resolved.

And I don't want to go into all of the time spend getting systemd unit files correct. There is very active community suggesting things you can add, which then of course breaks your release for users in unexpected ways. An enormous waste of time.

systemd-resolved responds on port 53. It inserts itself in /etc/resolv.conf as the DNS resolver that is to be used by DNS stub resolvers.

It can do whatever it likes as longs as it follows DNS RFCs when replying to DNS requests.

Redefining recursive DNS resolution as general 'name resolution' is indeed exactly the kind of horror I expect from the systemd project. If systemd-resolved wants to do general name resolution, then just take a different transport protocol (dbus for example) and leave DNS alone.