phicoh

Systemd-resolved invents DNS records (not really something you would like to see, makes debugging DNS issues a nightmare). But worse, it populates those DNS records with IPv6 link local addresses, which really have no place in DNS.

Then, when after a nice debugging session why your application behaves so strangely, all the data in DNS is correct, why doesn't it work, you find that this issue has been reported before and was rejected as won't fix, works as intended.

Depends a bit on how you define systemd. Just found out that the systemd developers don't understand DNS (or IPv6). Interesting problems result from that.

It's not that simple. For example, in the The Netherlands, the use of electricity was stable for a long time. Mostly because all kinds of equipment (light bulbs, etc) got more efficient.

Grid operators predicted that with the energy transition, demand would rise, but politics wanted to keep prices low and limited investments.

So now, there is a big problem in the entire country connecting companies or new residential areas to the grid independent of how electricity is generated.

At the same time, the government is extremely forward looking and builds massive interconnection points on the North-Sea. Not a bad idea in the long run, but in the short run it does make electricity from wind on sea more expensive.

That said, the biggest hit to EU countries is that cheap natural gas disappeared. Coal is not cheap and extremely polluting. Natural gas was cheap for a while. Until it wasn't.

I recently had this problem is some rust code. I was implementing A and had some code that would decide which of several 'B's to use. I then wanted to call an internal method on A (that takes a mutable reference to A) with a mutable reference to the B that I selected. That was obviously rejected by the compiler and had to find a way around it.

At the level of dnsmasq, I doubt they will care about resume.

CVEs are obviously important to you. I'm sure CVEs would be important to Dnsmasq, if they would get paid to handle them. So my guess is that they don't.

If they don't have the resources to deal with those CVEs (and I would certainly try to fix config errors that lead to crashes) despite being a hugely popular piece of software then they are just not going to deal with those CVEs, or report on them, etc.

The next step, given that Dnsmasq is used by big companies as well, might be to leave those CVEs out there on purpose. No money, no work.

If you expect that people are just not going to give you enough money then leaving out certain aspects of professionally maintained software is reasonable.

Those seems to be independent issues. Fil-C is about the best way to compile/run C code.

Rust would be about what language to use for new code.

Now that I have been programming in Rust for a couple of years, I don't want to go back to C (except for some hobby projects).

What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority.

We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts.

So you can turn the argument around, if you are not paying for software, consider it a hobby project. Feel free to report and issue and create a ticket. But don't expect anything to happen. And don't complain on mailing lists how your issue is not taken seriously. Just fix the issue yourself or switch to a different product.

This takes a rather narrow view at what is DNS.

For DNS as a service to work, it has to be accessible and give the right answers. It doesn't matter why it is not accessible or why it doesn't give the right answers. If it doesn't, then the service is broken.

DNS is in the unique position that it is relatively high up in the network stack, so lots of (network) failures affect DNS as a service. It is a big distributed database, which gives many possibilities for wrong data, it is used by almost all applications, so a failure of DNS as a service is highly noticeable.

Finally, DNS has by nature (some what) centralized choke points. If you have a domain like company.com, then just about everything that company does has to go through the DNS servers for company.com. Any small failure there can have a huge effect.

So DNS is a pretty exciting field to work in.

As an open source software vendor I can say two things: 1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously. 2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the money to do so. Just because you got a free download doesn't give you any rights to support.

True. Though there are plenty of people advocating for some small extensions to C to make it safe.

I didn't make a list, but let me give an example. Page 22 where variable declarations are introduced:

If a variable is declared and not given an initial value then great care must be taken not to use the undefined value of the variable until one has been properly given to it. If a program does use the undefined value in an uninitialised variable, its behaviour will be unpredictable; the program is said to be erronous.

Though one thing that makes Rust quite different from C is move semantics.

I recently started re-reading "Programming in Ada" by J.G.P. Barnes about the original Ada. In my opinion, it was not that good of a language. Plenty of ways to trigger undefined behavior.

Where C was clearly designed to be a practical language with feedback from implementing an operating system in C. Ada lacked that kind of practical experience. And it shows.

I don't know anything about modern day Ada, but I can see why it didn't catch on in the Unix world.

My conclusion is that C is not a good basis for what Rust is trying to do. The kind of reliability Rust is trying to provide with almost no runtime overhead requires a much more complex language than C.

If you come from C to Rust to basically have to rewire your brain. There are some corner cases that are wrong in Rust, but mostly you have to get used to a completely new way of thinking about object lifetimes and references to objects.

This fine. But from the fact that prices are sometimes high, we can conclude that overlll there is a shortage of windpower. Which will factor into the prices. The owner of the windpark can take the prices for each hour, and compute weighted average with production. And set that as the constant price.

So the consumer does not gain anything.

There is no reason for anyone with a wind park to sell cheap if there are customers willing to pay a high price.

That said with a battery and dynamic prices, there are many days where you can charge a battery when the prices are low and use them battery when the prices are high.

Sounds like a disaster waiting to happen. There will be a bug in that LLM generated code and then what? Ask the LLM to fix the bug?

By and large Garmin devices can be accessed directly from a Linux system. I have a FR 965 and it connects just fine.

But in typical Garmin fashion, there may be a hard to find setting to enable this. My watch asks if I want to connect to a computer when I plug in the cable.

The is no such thing as TAI. TAI is what you get if you start with UTC and then subtract the number of leap seconds you care about. TAI is not maintained as some sort of separate standard quantity.

In most (all?) countries, civil time is based on UTC. Nobody is going to set all clocks in the world backwards by about half a minute because it is somewhat more pure.

GPS time also has an offset compared to TAI. Nobody care a bout that. Just like nobody really cares about the Unix epoch. As long as results are consistent.

As a long time C programmer I like Rust because it combines two things from C that are important to me (low runtime overhead, no runtime system required) with a focus on writing correct programs.

Memory safety is just one aspect where the compiler can help making sure a program is correct. The more the compiler helps with static analysis, the less we need to rely on creating tests for edge cases.

As far as I know, the Unix group has to promise to build a document processing system to get the pdp-11 they needed.

Building Unix was a specific non-goal of Bell Labs as a result of their experience with Multics.

It was the perseverance of the Unix group that made them get the resources they needed.

The thing the consider is who is the first to send data over the connection.

If it is the client, then a two-way handshake is enough: client sends a SYN, server sends a SYN+ACK, then the clients data which ACKs the server's SYN. These days that is the most common model. HTTP and TLS work like that.

However, what if the server sends first? For example the banner of SMTP. In that case the client sends a SYN, the server sends a SYN+ACK, the client sends an ACK and only then the server start sending data.

In general, an operating system doesn't know what is going to happen. So the client's kernel will just send the ACK immediately even if it will be followed by a data segment shortly after.

I think long term, FreeBSD may lose out if Rust in the base system is not supported. Note the 'may'. It is hard to predict the future in this regard.

Where I work, we have some open source C code that is also in the FreeBSD base system. We have decided to create new code in Rust and look into deprecating the C code. Obviously, the FreeBSD project can just take over maintenance of the C code, but that will be burden to the project.

Note the 'may' and 'long term'. But for a project like FreeBSD it is good to look at Rust before it becomes an issue.

A more silent problem, it is quite possible that Rust programmers are less likely to contribute to a project that is based on C and C++ where Rust is not welcome. Certainly when new code is needed, that group will wonder why it needs to be written in C or C++.

That is because Mozilla has consistently moved Firefox in the direction of a Chrome clone.

When Firefox started is was not a copy of existing browsers. There is no reason it would have to be now. But they have rejected their core users. So now the only option left is a Chrome clone because that is what people are used to.

Firefox market share is going down.

One reason is that the people who would be promoting Firefox aren't.

Personally I feel mostly ashamed to admit I'm using Firefox. In theory Firefox is great. In practice they coming up with new ways to treat their core user base badly.

Yes, but that does not mean that the actual heater can run in a low power output mode for a sustained period of time.

Then you are talking about something else. If the return temperature is below 40 degrees then the condensing mode kicks in. This can typically be achieved if the system is set to 60 degrees. Most radiators for this type of system work well with a temperature drop of 20 degrees. Obviously the flow should be adjusted accordingly.

If you go lower, efficiency may increase by tiny amounts, but in most practical setups the system is likely to become unstable and you will lose more than you gain. This is especially true if the system is also used to provide hot tap water. For hot tap water, in particular for a shower, the system needs to be able to heat a lot of water quickly.

It is worse for heat pumps. For condensing boilers the return water temperature needs to be low enough, but the system can easily be set to 60 degrees.

For heat pumps, 40 degrees is about the max for efficient operation. So radiators need to be quite a bit bigger compared to what you need for a condensing boiler.

Do you have any source that it is 22 degrees for the entire UK? That seems unlikely.

There is no reason to set all units to the same value in the entire country.