Posts by thames

Re: just a thought

In Toronto the district heating system also provides cold water for air conditioning in summer. The municipal water system draws water from several kilometres offshore deep in Lake Ontario where the water stays cool (4 C) year round. This water is then run through heat exchangers to cool the water in the district air conditioning loops. This then provides air conditioning to several hundred buildings, saving about 75 per cent of the electricity which would otherwise be required for air conditioning. The water being used for cooling is already being drawn for municipal water supply anyway, so there's no additional water being used.

Toronto also gets the majority of its electricity from nuclear power, with more plants being built close by. The nuclear power plants also draw their cooling water from either Lake Ontario or Lake Huron. The Great Lakes are large enough that the amount of heat being discharged into them is insignificant compared to their size. In winter only a very small area outside of the cooling discharge outlet doesn't freeze, so it's easy to see that the amount of heat involved may be large on a human scale but is very small on a geographic scale.

If data centres need lots of electricity and cooling water then they need to start locating in places where these resources are abundant and stop building in places where they are lacking. As can be seen with Toronto (natural cooling water and nuclear power), there are solutions and they are practical even if they are foreign to Silicon Valley.

Re: “Minimal adjustments”

The HACL conversion to Mini-C required only minimal code changes, and the EverParse conversion required no source code changes at all. Just because the C language has some problematic features doesn't mean that your C program uses any of them.

So, hypothetically we could create a "Mini-C" compiler and add things like "fat pointers" and run-time bounds checks to it. Then see if our C program compiles with it and passes its tests. If it does, we're done without using Rust and with no source code changes, just a recompile.

If there are a few spots in the program which need features that Mini-C doesn't have, then factor those out as separate regular C files, and include them in the project, just like Rust does with "unsafe" code. We're then done without using Rust and with limited source code changes.

Perhaps Rust would handle a few corner cases better than a hypothetical Mini-C, but if a C variant can do 90 percent of what Rust provides it would be more likely to be widely adopted sooner and so provide more security in a practical sense when looking at the industry as a whole.

If just replacing existing code bases with a new language was simple, easy, and cheap, all that COBOL code out there would have long ago been turned into Java. That hasn't happened, and I similarly suspect that C will be around for a very long time to come and lots of new C code will be written.

Re: SMRs are a scam

There are economies of scale to most electrical generating plants, regardless of the technology used. For nuclear reactors many of these are associated with the civil works such as site prep, roads, cooling water channels, grid connections, etc. This is why so many power plants have multiple units.

New "conventional" SMR designs have optimized their layouts to have reduced footprints in order to require smaller civil works, and also to use less concrete by making the reactor building more compact (so there is less to enclose).

Existing heavy water moderated reactors, such as the CANDU, which are in commercial operation around the world, can use thorium as fuel. India uses thorium as part of their fuel load in their CANDU derivatives. India do this mainly because they have lots of thorium but much less uranium, and they want to reduce their dependence on non-domestic supplies.

For most countries though, uranium is so cheap that it simply isn't economic to use the more complex and expensive thorium fuel. Reactors fuelled entirely with thorium will not "self-start". They need either enriched uranium or plutonium (reactor grade, not the special isotopes used in bombs) to start the reaction and create U-233 from thorium to run the main reaction.

At this time, it is cheaper to simply use abundant supplies of uranium in a once through fuel cycle than to set up the chemical reprocessing facilities to recycle spent fuel into mixed-oxide (MOX) uranium or thorium based fuel. France do it (for uranium based MOX), but that was a decision made based on national security to reduce reliance on uranium imports.

If uranium prices rise high enough, then there are already reactor designs that can use uranium or thorium based MOX fuels, and these reactors have been in large scale commercial operation in multiple countries around the world for decades. They just don't happen to be used in the US, which is why the US-centric media don't talk about them much.

To expand on what you said, "orphaned wells" are oil and gas wells where the previous owner went bankrupt and the bankruptcy trustees couldn't find another company anywhere who were willing to touch them because they're worthless, and indeed an overall liability. The wells that are actually worth operating get bought up by another oil company.

In Canada orphaned wells end up in the hands of the provincial government and the cost of sealing them is paid by a fund which all oil companies must pay into (in Alberta that fund is grossly under funded in terms of future liabilities).

The idea of a crypto-mining company somehow succeeding at operating oil and gas wells where the entire industry of actual oil companies looked at it and decided to pass is a bit odd, to say the least.

I find it utterly implausible that anyone promoting this idea actually believes what they are saying about it. The fact that someone is promoting it tells me what should be obvious to anyone, it's a scam.

Canada and the US have a long standing treaty which allows either country to send illegal immigrants back to the other. There was a loophole which allowed people to claim refugee status at official border crossings, but this was closed a couple of years ago with an new treaty. Now refugee claimants can get tossed back for the original party to deal with.

The new treaty was signed when Biden was going to visit Canada and was told that the number one issue the Canadian press were going to ask him about was the flood of illegal immigrants from the US crossing into Canada (it's mainly from the US to Canada) through the refugee loophole. Suddenly, a treaty which the US (including Trump) had for many years insisted was not possible for the US to sign was suddenly possible and got signed and approved in short order in time for the visit by Biden.

Prior to that the biggest issue that Canada had with the US was illegal immigrants coming from the US to Canada, while the Americans (including Trump) claimed they could do nothing about it. Canadian opposition politicians were demanding that Canada build a wall to stop it, although nobody was suggesting that the Americans pay for this one.

Most of the border is actually not that easy to cross illegally. Most if it is either in very remote areas, or lakes and rivers and mountains. Both are monitored closely. The border is where it is because it was a defensible line dating from a series of UK-French, and later US-Canada wars. Canada faced a long running invasion, insurgency, and terrorism threat from the US through most of the 19th century.

There is still a smuggling problem, with most of it being drugs and guns from the US being smuggled into Canada in shipments of goods. The US import drugs from places such as South America and Asia, and organized crime gangs arrange for them, as well as US made illegal guns (mainly pistols), to be smuggled into Canada.

The biggest single problem is probably an Indian Reservation which straddles the border south of Montreal. It's technically two separate reservations, but the residents have special treatment from both countries which allows them to travel freely between them without passing through customs and immigration. Native organized crime gangs have heavily infiltrated local governance and police (they have their own police forces) on both sides of the border, and smuggling of everything from cigarettes, to drugs, to illegal immigrants is a major industry. Their proximity to Montreal and New York means they have very good transportation links to distribute their goods everywhere. Doing something about it means making coordinated changes to treaty arrangements by both countries with both reservations, but that is a hugely sensitive historic political issue so nobody has done much about it. Trump completely ignored it the last time around, so I doubt he'll do anything this time either.

Re: "At 300 MW, these SMRs are not drastically bigger than Pickering's 500MW reactors "

Yes thank you, it should have been the new Hitachi SMRs are not drastically smaller than the reactors at Pickering.

As for build time, they did site prep work for all 4 units this past autumn. Construction of the nuclear works will start in early 2025, and the first unit is expected to be in commercial operation by 2029. This fairly quick, so the concrete work doesn't appear to be a serious bottleneck.

As for the type of steam turbines used, I don't think anyone really cares. Ontario gets the majority of its electric power from nuclear energy and has for many years, so the steam burbines seem to work just fine as is.

The UK AGR (Advanced Gas-cooler Reactors) were designed around the idea of being able to use high temperature steam turbines and higher thermal efficiencies, but the practical benefits of this were much less than the problems associated with higher temperatures. The AGR design proved to be a technological dead end, as has every other high temperature reactor.

Oklo's reactor is a liquid metal cooled fast neutron reactor. A number of countries have built these types of reactors over the decades and found them too complicated, expensive, and impractical. I haven't seen anything which would lead me to believe that Oklo's design will be any better.

The SMRs being built at Darlington are based on well proven technology. However, Ontario are also planning to build large nuclear reactors as well, again based on existing technology.

Re: Long Time VirtualBox User

I switched to KVM from VirtualBox mainly because VirtualBox VMs were randomly hanging. The final straw was that after an update VirtualBox wouldn't run at all and it took several weeks for another update to fix that. I haven't had any problems at all with KVM so far. However, I had been using VirtualBox for years and my experience with KVM has been a matter of months so far.

For what I'm using it for (software testing) both offer equivalent functionality. However, the virtual network connections for KVM were much easier to use than was the case for VB.

I'm not a patent lawyer, but from a user perspective Gnome 2 was as far from Windows as any GUI that I've ever used, except perhaps Windows 3. I was originally using Mandrake (later Mandriva), and the default install included both KDE and Gnome (it was a big stack of CDs).

KDE was very Windows-like, and I had no difficulties adapting to it.

Gnome 2 on the other hand seemed to be from another planet and I would look at it, find the concepts alien, and then go back to the very Windows-like KDE.

However, Mandrake/Mandriva started going down the tubes (new management brought in by investors), and I had to find an alternative. After evaluating what was out there, I settled on Ubuntu. The default desktop for it was Gnome 2, so I decided to suck it up and get used to it, learning it bit by bit on Mandriva until the day I was ready to make the big jump and install Ubuntu instead.

Gnome 2 was alien, but it was actually pretty good, once I got used to it. I wasn't afraid to try something new, and I felt that Gnome 2 was actually easier to use than Windows in terms of getting things done.

However, Gnome 3 was a different story. Instead of just being an adaptation of Gnome to the new GTK version, they decided to exercise their creativity and strike out in a "bold new direction" in user interface concepts. This was the classic example of group of programmers trying to be innovative UI designers and not really understanding how the average person thought or interacted with a computer. The result was a design which required a lot of mouse movement from one side of the screen to the other to get anything done. Using early Gnome 3 for an extended period of time has been compared to be like sawing wood.

As for Unity, they dropped broad hints which said the UI designer contracted by Canonical (the report was published and free to use by anyone) had in fact been heavily inspired by Apple Mac. This wasn't just a matter of the window control buttons being on the left, but also the function (although not location) of the dock and other things. They didn't say it outright though, as that would invite lawsuits from Apple. I can't give you a source for this, but I did read about it in various articles. I wasn't familiar enough with Apple Mac to make that connection myself.

When the Gnome 3 developers finally realized that they were on course to being a footnote in computer history and put their misguided "creativity" back in a box on the shelf, then it started becoming more like Unity.

When Gnome 3 progressed far enough, Ubuntu was eventually able to ship a version of it with extensions that made it very similar to Unity. I found the transition from Unity to Gnome 3 completely seamless as a result. I still put the window buttons on the left though, as that makes more sense from an ergonomic perspective (most of the other things the mouse needs to do are also on the left).

Two explanations have been given for the dock being on the left side of the window in Unity (and later in Ubuntu flavoured Gnome). According to the pundits it was to avoid lawsuits from Apple. According to Canonical it was because modern monitors were much wider than they were tall, so the Unity UI design contractor said it made more sense to use horizontal screen space than vertical screen space. I suspect the latter is the correct reason. It does make more sense to have it on one side of modern wide monitors.

As for the Windows keyboard UI, that was copied from OS/2 when that was a joint project with IBM, and cane from inside IBM as CUA (Common User Access Guidelines). This was intended to provide a common user experience across IBM's product line, from mainframes (I don't know how that was supposed to work), to minis, to Unix workstations, to PCs. Microsoft kept that when they split off and went in their own direction with Windows.

You can find IBM CUA if you google for it. It was considered to be public spec which was free for anyone to use. It's no surprise that Linux distros implemented it instead being different for the sake of being different.

As I understand it the reason why updates work so smoothly on Linux compared to Windows has a lot to do with file system semantics. Linux follows unix file system semantics where old and new versions of the same file can co-exist side by side until the last user of that file releases the file handle and then the old version goes away. So, you write the files to disk and the applications inherently automatically use the new versions when they restart. Long running daemons can be sent a restart signal, but again, that's a long established practice.

Windows file systems don't do that, instead they have locks preventing a new version from being installed until the last user of the old version has released it. Thus you have the update, reboot, update some more, reboot again cycle.

For both operating systems, these assumptions are baked into applications, not just the OS itself. This makes changing Windows to work more like Linux (unix) is probably very, very, difficult and would likely break an unknown number of business applications in the process.

As I understand it, Flatpack isn't really able to a lot of things which Snap can. It was a very narrow solution to portable packaging of GUI apps rather than a general solution for software in general.

Snap evolved out of Ubuntu Phone, and was one of the bits of that project which were later repurposed for other things. Currently it's being used for embedded and cloud applications. What's different about Ubuntu Core as compared to at least some other immutable OS projects is that the actual OS part is broken up into several smaller snaps which can be exchanged in a mix and match fashion rather than being one big chunk.

As stated in the story, what they are trying to figure out now is how to split the desktop up into multiple chunks as well. From the sounds of it they want something that works for KDE and possibly others as well, and not just a Gnome only solution.

Re: Why?

The issue is that to convert a C program to a "proper" Rust program you have to approach a lot of things in a different way. Rust is not simply C with different key words.

If you want an analogy, then if you've done much Python programming you have probably seen Python programs that were either directly translated from C or Java, or written by people familiar with C or Java and are just writing their Python program the same way they write a C or Java program. This is a well known phenomenon in Python and is immediately recognizable by people with experience with the language. The end result is something very verbose and slow because the Python language is being used in ways it was never meant to be in order to make it work like a different language.

With C and Rust, there have been multiple machine translation projects, including AI based, but the results have been very disappointing. You simply end up with a C program that is written in Rust rather than a "proper" Rust program, and you probably haven't made much if any use of the memory safety features which you were converting to Rust for. So why bother?

The answer would seem to come down to either completely replacing all existing C and C++ programs with ones written in other language (like that's ever going to happen), or else address the problem in a different way, one that nobody has really come up with yet.

Re: ?

The story is not going to make any sense to you if you don't live in Canada and been following the Canadian news. This story doesn't mention any of the background to this announcement but instead goes on about completely unrelated American issues, so there's no reason why you would understand it.

One of the top long running stories over the past couple of years has been about security problems originating in foreign countries. The Government of India have been running around assassinating Modi's political critics in Canada, Saudi Arabia and Iran have been doing their own dirty deeds, and Chinese people have been saying negative things about Canadian politicians on WeChat.

A long running revue committee is just wrapping up their report on all this, and so the government have to be seen to "do something" in order to cut off the press reaction.

Now they've "done something" and so the whole thing can be put behind us and we can get on to the next issue. India will still murder Modi's political critics in Canada, Saudi Arabian security agents will continue to show up at the airport in Toronto with bone saws in their luggage and evasive stories about the reasons for their visit to Canada, and Chinese people will still call Canadian politicians insulting names on WeChat, but we are now safe from, well, something or other.

It's like the Huawei / Meng story from a few years ago. If you didn't follow the Canadian reporting on what actually happened you ended up reading the wildly distorted and inaccurate version circulating in the international press and so would have no idea what was going on or how it all started or ended.

Re: A quite generous move...

Yes and no. Different clouds from different vendors are different enough that optimizations based on this data may not be directly applicable to a cloud from another vendor.

On the other hand, detailed data of this sort may attract the attention of independent academics who want to use it to do research on coming up with new optimization algorithms which Huawei may be persuaded to test for them.

If the above is the case, then other companies may benefit to some degree, but Huawei may benefit the most.

American auto companies had stopped making lower priced cars and focused on expensive ones for several reasons. One reason was the chip shortage meant that production was limited by parts availability, and so they focused on high end models with high profit margins. The other main reason was that very low interest rates, virtually zero, meant that finance costs were very low.

Both effects have gone away, and auto industry news is talking about the panic in Ford, GM, Stellantis (Chrysler), etc. that they don't have low cost models to sell.

Average selling prices of new and used cars are falling in the US. The analysis of the situation being talked about by auto industry analysts is that the people can afford and want an expensive car already have one, and the ones who either can't afford an expensive, or can afford it but aren't interesting in spending their money on a car, are holding off buying, and when they do buy, they buy the cheapest one they can find. The result is that storage lots are full of expensive cars that can only be unloaded at deep discounts.

General opinion seems to be that the auto makers need to offer low cost cars if they want to stay in the mass market. That means smaller, simpler cars without a lot of the useless crap which drives up the price.

The Chinese are already selling cars like that, in both electric and non-electric models. The danger for the American makers is that Chinese companies will gobble up the global market outside of a protected American bastion, leaving the American industry like the British auto industry of the late 20th century.

The American companies know this, and they also know that the people who dismiss the Chinese auto makers are like the ones who did the same with respect to the Japanese in the 1970s. The head of Ford knows this. The people who don't know it are people who are living in the past, just like 50 years ago with the Japanese.

Re: x86 Train Wreck

The compiler won't in most cases use a lot of these optional features because there is often no way of expressing them in a generic portable high level language such as C. Your options are generally either assembly language or compiler extensions (which allow you to specify assembly language instructions in the middle of a C program).

In some cases the compiler will automatically use some features if present, but generally only for very simple cases. In many cases you need to actually use a different algorithm to be able to use the instructions effectively. That isn't something that compilers are good at figuring out for themselves. You could easily need to use one algorithm for floating point, another algorithm for unsigned integer, a third algorithm for signed integer, and a fourth algorithm for non-optimized generic C for fall-back mode. Been there, done that.

I have an open source C project where I support Linux, Windows, and BSD. Windows users get a pre-compiled binary without optimizations because many Windows users don't have a compiler installed and asking them to install one is asking a bit too much.

Linux and BSD users get a source distribution only because unlike Windows installing a compiler there is very easy. The Linux build script looks at the CPU flags to see if it has the optimized features. If so, it compiles for these (there are a bunch of if-defs in the code). If the flags are not present, it uses generic fall-back mode.

BSD users also get the generic fall back mode because while Clang LLVM is reasonably GCC compatible, one of its weak areas is poor support for compiler extensions. They try to make up for it with automatically using the instructions if present. This is good when it works, but usually it doesn't because as I said, you actually need to write a different algorithm in many cases, one that can't even be expressed in standard C (which is a lowest common denominator language, for the sake of portability).

Now take all of these different versions on different platforms with different compilers, and realize that each of these has to be not just written and maintained, but also tested. You need to have a very thorough automated testing system for each of these combinations.

ARM has been a different story. I have 32 and 64 bit versions, but as an application (as opposed to OS) writer, ARM has been a pleasure to work with compared to x86. OS initialization has been more difficult on ARM (due to lack of boot standards on different boards) but that isn't something that has affected me as an application level developer.

Re: Is it genuine?

The point of making the reactors smaller is to be able to assemble as much as possible in the factory rather than on site rather than having really large bits that have to be assembled on site. If the Rolls Royce SMR is transportable in assembled form then the larger generating capacity may be an advantage in terms of cost per MW.

There are significant economies of scale when it comes to the civil works - roads, sewers, transformers, switch yards, transmission lines, cooling water inlet and outlet channels, etc., which make larger plants more economic. This is in addition to being able to make better use of manpower when a number of units are co-located. Scattering small plants all over is very sub-optimal.

The really small SMRs seem to be a lot less successful in terms of actually getting bought by customers than the larger ones.

Re: Regardless of the veracity of the allegations...

I think the focus is more on RISC-V and Loongson rather than x86 clones. The only reason to use x86 is either for Windows compatibility or to use commodity hardware designed to run. Windows is just as problematic or even more so when it comes to US back doors so plans are to phase it out as well (this is already well under way).

Current policy in China is to phase out both x86 and Windows in all government and critical infrastructure use and replace them with RISC-V or Loonson and Linux. This is for a combination of security and to simply get away from all the massive delays and pointless paperwork and expense associated with dealing with American companies and their US sanctions compliance bureaucracy. Private industry and the consumer market are expected to follow once the economies of scale that comes from supplying the government market ramp up.

Europe (EU) and India are going the same way, although they aren't as far along. With both of these it's driven by a desire to get away from increasing US control and also to help develop their own technology industries. There has long been an entire industry in Europe based around making and selling high tech kit that is certified free of US content in order to avoid dealing with US bureaucracy on re-export of goods which would otherwise include US content as one or more of its components.

Re: Nuclear power for everyone?

I'm not sure what you mean by "Canada threatening to shut down their CANDU reactors". Existing reactors are undergoing a program of refurbishments, a few at a time. There are no plan to shut them down permanently though, indeed they are building more. They produce the majority of electric power in the province of Ontario (40% of the total population in Canada).

Currently cobalt 60 (half the world's supply) is made at the Pickering and Bruce B plants. There are plans to add production at Darlington to accommodate refurbishment programs at the other plants. They will also add production of molybdenum 99 while they are at it.

I think they just shove a dummy fuel bundle containing the source cobalt or molybdenum through one of the fuel channels and catch it when it comes out the other end (the reactors are refuelled continually by shoving fuel bundles through the reactor, they don't shut down for refuelling). I suspect the main thing they need to do is to add special handling systems for the irradiated medical isotopes when they come out.

Overall it's a nice little earner, and it's done as part of the normal operation of a generating plant instead of building a dedicated reactor to do this. The design of the reactor makes it fairly straightforward to do.

Re: Seems to work for the basics

It might help to actually read a post before you hit the reply button. The standard shell for /bin/sh in Ubuntu and Debian is Dash - Debian Almquist Shell, which is a POSIX standard shell.

The standard interactive shell is Bash (/bin/bash). If your shell script just asks for /bin/sh you get Dash, not Bash. If you open a terminal to interact with or your script asks for /bin/bash you get Bash. The majority of Linux distros are Debian derivatives, so most of them do the same. I can't speak for Red Hat or Suse derivatives on this.

However if you google for answers to questions about shell scripting nearly all the answers you get will be for people assuming you are using Bash, even if they do not explicitly say so. Therefore if you decide to use pretty much any BSD you need to know your shell scripting well enough to distinguish between standard shell syntax and Bash extensions.

The Bash extensions are very nice to have, but they are Bash specific and don't work in Dash, let alone any of the BSD shells. This is something that anyone trying out BSD needs to be aware of. Therefore don't copy-paste shell scripts from the Internet without having a good look over them for Bash specific extensions.

Re: Also in Python

Here's the overview of how Tkinter works, from the Python documentation:

https://docs.python.org/3.12/library/tkinter.html

When your Python application uses a class in Tkinter, e.g., to create a widget, the tkinter module first assembles a Tcl/Tk command string. It passes that Tcl command string to an internal _tkinter binary module, which then calls the Tcl interpreter to evaluate it. The Tcl interpreter will then call into the Tk and/or Ttk packages, which will in turn make calls to Xlib, Cocoa, or GDI.

It appears to me that there must be a Tcl interpreter embedded in the Tkinter package. You as a Python programmer don't see any Tcl, but it's still there underneath.

Re: VMM

You are correct in that snapshot management is there in KVM VMM on the console window (the window that opens you click the console button).

If you right-click on the snapshot number you can start or delete that snapshot. I had not noticed that I could bring up a context menu using right-click, I had thought I could only see them listed.

However, I don't see a way to create a snapshot using VMM. If it's there, it's not obvious to me. If I can't create a snapshot using VMM, then I don't see the point of deleting them using VMM, at least not for my use cases. Creating and deleting snapshots via the command line is not difficult however.

Overall I am still happier with KVM than I was with Virtual Box, and I find that VMM does pretty much everything that I want from a GUI tool.

I will probably write a bash script with a Zenity GUI to handle any routine VM chores involving snapshots (I need new snapshots after doing updates). I had been thinking of doing the same for VirtualBox, as even if the GUI can do it, it still needs multiple steps and it's possible to make mistakes in the process. Automating it via scripts is the way to avoid that.

Re: My understanding...

This is pretty much my understanding of it as well. Rust is not simply C with some stuff added, so code has to be written to interface between the two. Every time some C code is changed, Rust code which uses it may change, even if the function call interface is the same. The question is who is made to be responsible for those changes.

There was some other large C project which had some Rust dramatics a while ago where the Rust enthusiast had promised that his Rust bit of the project wouldn't affect anyone else. He was allowed to introduce Rust on those terms. However, he found the maintenance of his Rust code a major burden and so was trying to push that work off onto everyone else, under the guise of "he just needed them to provide information", when in reality he wanted them to maintain the Rust code so he could go on to write more new Rust code instead of spending all his time chasing a moving target with Rust. I think he wrote a small program to automatically re-write the Rust interfaces, but he wanted everyone else to be responsible for writing the necessary inputs to it, which meant they needed to do a lot of extra work when the conditions for introducing Rust had been otherwise.

There was massive push-back from everyone else, and the Rust enthusiast ended up bailing out of the entire project in a huff while blaming everyone else. Unfortunately I can't recall the name of the project at this time, although I think it was covered in El Reg.

One of the major problem with trying to use Rust in a C program is apparently that while Rust does offer interface options for working with C, you lose most of the supposed advantages of Rust if you make use of them, including many of the memory safety features. And once you do that, why bother with Rust?

I suspect that what is really needed is rather than having a completely new language is for someone to create a new variant of C, but without a lot of the baggage associated with C++ and just focuses on the major security pain points in C as experienced in the Linux kernel. This would allow for a gradual re-write of the kernel without the dislocation of using a completely new language.

After the BitKeeper fiasco Torvalds went away for a while and came back with Git. Perhaps he could do the same with C.

Re: Hyper-V Type1

KVM can be type 1 or type 2, depending on how you use it. Type 1 is basically a hypervirsor with no underlying OS, while type 2 runs as an application managed by an OS. Type 1 hypervisors may not need a separate OS to run them, but that's because they have all the features of an OS built in already. What you are using it for and how you are using it determines which type you need.

KVM is a Linux kernel module, so if used in a minimal installation it can be seen as type 1, but if you install it on your regular Debian (or whatever) desktop OS, then it could be seen as type 2.

In reality its both and neither, it's a hypervisor built by people who didn't care what the marketing people wanted to label it as.

As mentioned in another post, I am in the midst of switching from using VirtualBox to using KVM as a desktop hypervisor, and have found the two to be more or less equivalent for my purposes (software testing). Because KVM is part of the Linux kernel (it's a kernel module), I expect that it will be much better maintained than VirtualBox has been under Oracle's care.

Re: Starlink? What about starlight?

This was an experiment to show that Starlink satellites in particular could potentially be used as sources of ambient radio signals for passive radar. If there are also other signal sources which could also be used, then that would have to be a different experiment.