Posts by thames

OpenBSD 7.3 won't install in VIrtualBox

I installed both FreeBSD and OpenBSD in VMs on Tuesday. FreeBSD installed without any problems.

OpenBSD 7.3 however crashes during the installation process. I eventually ended up installing 7.2 and then did an upgrade to 7.3, which went fine.

I just repeated the attempt with a new download a few minutes ago before making this post. It's not clear what the problem is. The VM is VirtualBox 6.1.38 on Ubuntu 22.04.

I install all the major Linux distros and BSDs in VMs for software testing, and this is the only one which is giving me this sort of problem. Aside from that, it worked fine once it was installed and running.

One thing that I did notice is that in OpenBSD the Python version has been upgraded to 3.10 from 3.9, while with FreeBSD it remained unchanged at 3.9. This isn't a problem (I welcome it in fact), but it's worth noting that a change like this has been made in a point release.

I suspect that Baidu have a list of things they are interested in using RISC-V for, but are not making solid commitments to any in particular on any specific time line until they've done some researching and testing.

Overall though, I expect them to shift to RISC-V over a period of years. Anything else is too much of a risk given the current international environment.

We can probably expect to see India going down the same road for the same reasons, just a few years behind though.

Already solved in a Canadian investigation made at the time in question

Canada investigated the problem and fairly quickly found it was due to excessive use of pesticides during the zika virus outbreak in the Caribbean at the time. A US contractor from Florida was used to fumigate the embassies and staff housing with organo-phosphate pesticides.

Due to the panic over zika at the time (the virus was causing serious birth defects), the fumigation was carried out much more frequently than normally recommended. The result of this was that people were exposed to toxic levels of pesticides.

Blood samples of Canadian diplomats found above normal levels of organo-phosphate pesticides. The symptoms associated with this are consistent with these associated with so-called "Havana Syndrome", including hearing sounds that aren't there and the rest. Examination of the patients also found nervous system damage consistent with pesticide poisoning. Organo-phosphates affect the nervous system (some types of organo-phosphates are used as military nerve gas), so effects on the brain are entirely to be expected.

The US government were aware of the Canadian medical investigation but chose to ignore it. Hypothetically this may have been due to concerns about the finger of blame (and lawsuits) coming back on the US officials who approved the use of excessive amounts of pesticides.

Not sure the evidence is there

El Reg referenced two studies. The link to one appears to be broken, but the Singapore study titled "Comparative effectiveness of 3 or 4 doses of mRNA and inactivated whole-virus vaccines against COVID-19 infection, hospitalization and severe outcomes among elderly in Singapore" had this to say:

"As BNT162b2 and mRNA-1273 were recommended over CoronaVac and BBIBP-CorV in Singapore, numbers of severe disease among individuals who received four doses of inactivated whole-virus vaccines or mixed vaccine type were too small for meaningful analysis." So, we may not want to draw too many conclusions from that study.

Another comparative study which is widely referenced is one in Brazil titled "Effectiveness of CoronaVac, ChAdOx1 nCoV-19, BNT162b2, and Ad26.COV2.S among individuals with previous SARS-CoV-2 infection in Brazil: a test-negative, case-control study"

June 01, 2022

Here's the link to the article in The Lancet (a major UK medical journal).

https://www.thelancet.com/journals/laninf/article/PIIS1473-3099(22)00140-2/fulltext

It had this to say:

"Effectiveness against hospitalisation or death 14 or more days from vaccine series completion was 81·3% (75·3–85·8) for CoronaVac, 89·9% (83·5–93·8) for ChAdOx1 nCoV-19, 57·7% (−2·6 to 82·5) for Ad26.COV2.S, and 89·7% (54·3–97·7) for BNT162b2."

The vaccines referenced are CoronaVac, Oxford AstraZeneca, Johnson & Johnson, and BioNTech/Pfizer respectively.

In other words, the Johnson & Johnson is not very effective, but CoronaVac seems to be only marginally less effective than Oxford-AstraZeneca or BioNTech-Pfizer in terms of hospitalisation or death.

Efficacy against infection is less impressive, but the same is true for the rest of the vaccines as well.

There are two main components in your immune system which vaccines stimulate. Antibodies prevent infection, but they are short acting (weeks or months at most) and sensitive to changes in variants. T-cells prevent severe hospitalisation or death and are both much longer lasting and far less sensitive to changes in variants.

The big problem in China isn't that their vaccines don't work. The problem is that the older people are the ones who are least likely to have gone out and gotten their jabs and the younger people are the most likely, while in many Western countries it's the other way around.

What this suggests it that there will be plenty of symptomatic infections among the general population, but hospitalisation and severe disease is likely to be mainly in people who are unvaccinated.

Since in China the unvaccinated are mainly the elderly who are much less likely to be part of the working population, the economic effects are at best unclear.

Among the working population there may be plenty of short term work absences due to mild illness, but we saw the same in Western countries a year ago when the omicron wave swept through and that didn't shut down the economies there.

I'm making no predictions here, just pointing out that it's a bit soon to be predicting pandemic induced chaos in the Chinese economy as the evidence isn't there yet.

That doesn't mean to say that there won't be plenty of unfortunate deaths, but the kit you've got on order from China may arrive safely after all.

Opaque Types

The story missed one of the big features of the language, which was "opaque types". This was a different approach to solving the same problem as object oriented programming was trying to address at about the same time.

The name of an opaque type would be declared in the module interface, but any details of what it actually was would be hidden in the implementation, and so not visible to anything outside of the implementation (interface and implementation were defined parts of each module, and in separate files).

The interface would also declare functions which would take the opaque type as a parameter, and so allow you to manipulate it. Anything outside of the module however couldn't do anything with the type directly.

Overall it was equivalent to an object's attributes and methods, but defined at the module level. It differed from objects however in that there was no internal state to the module, you needed to pass around the opaque types explicitly.

I did several projects using TopSpeed Modula 2. It was probably by far the best compiler, IDE, and debugger available for MS-DOS PCs in that era. I also had their C compiler as well.

If I had any criticism about Modula 2 it was that screen I/O was a lot of work due to the strong typing of the I/O. Every data type had its own output function, and even newline was a separate function. C's printf may be complex and sloppy, but it's also a lot less work to use.

I liked Modula 2 a lot at the time, but I don't think it's going to make a come back. The industry went firmly down the object oriented route and Modula 2's opaque types are an interesting but forgotten side diversion.

Been using it for almost a year.

I've been using AlmaLinux as a replacement for CentOS for automated software testing for almost a year now, and I've had no problems with it that I can recall. I can recommend it for that purpose without hesitation.

I was motivated to use it by CentOS dropping support of their then latest release. I had to either pick something new or drop Red Hat as a supported distro for my software project. AlmaLinux was a straight drop in replacement for CentOS.

I want to congratulate Lord Raglan and Marshal Saint-Arnaud for their success at Alma, hard fought it no doubt was. With that out of the way Sebastopol should be within their grasp before long. Hurrah!

The view from Canada was a bit different.

As I pointed out in the comments in the comments to the previous story (which El Reg references in this one), the whole story was very badly reported on by the international press, who mainly just reprinted US official spin. The Canadian press attended the actual trials and their reports gave a very different picture.

To summarize a few points, the reason the US charges were constructed as "fraud" was to get around Canadian extradition law ("dual criminality"). Sanctions charges would have been tossed out by the court in Vancouver immediately, as Canada was still part of the European deal with Iran so no sanctions laws were violated in Canada. The US therefore constructed a very convoluted argument that "fraud" was committed because fraud is illegal in Canada, and they knew the judge in Vancouver was not able to take into consideration whether there was a genuine fraud case against Meng, just that fraud was also a crime in Canada and the US was charging her with that.

Meng's lawyers were able to obtain copies of documents directly from HSBC which contradicted versions provided by the US as evidence (they needed to show that they had some sort of evidence). The US versions of the documents turned out to have been edited by the US to remove significant exculpatory evidence. However, the extradition judge didn't consider these documents, as they were evidence of Meng's innocence and Meng's guilt or innocence could play no part in an extradition hearing which was only concerned with whether the right paperwork had been filled out and whether Canadian officials had behaved legally.

Canada is in the process of revising its extradition laws due to systematic abuse of the extradition processes by allies. This was already on the agenda before the Meng case and so had nothing to do with that. France in particular were notorious for extradition cases which turned out to lack substance upon actual trial. The extradition review is now back on the table after having been sidelined by the pandemic.

The Meng extradition case seemed to be on the point of collapse on abuse of process grounds when the US suddenly reversed course and decided they wanted a "deal" instead. Meng's strongest arguments against extradition had always been on abuse of process grounds, and the hearings on that were about to start when the deal to drop the extradition was reached. The evidence before the court showed that Canadian police and immigration officials had been doing illegal favours for their US counterparts, police were suddenly reversing their testimony and contradicting their written notes, and one of the key senior police witnesses had left the country (to go to Macau!) and had hired a lawyer to try to fight having to testify. There were a lot of people who may have found to have been involved in a lot of unsavoury activities if the hearings had proceeded. This sort of thing probably goes on all the time, the police just weren't used to dealing with someone who had the money to hire the lawyers to fight it.

A series of senior retired Canadian diplomats and cabinet ministers had advised Ottawa that they had sufficient grounds to toss the case on final review (this would have followed a judges decision). Trudeau however was desperate to avoid getting dragged into the issue because he had just taken a major kicking at the polls over the SNC legal scandal and wanted to avoid anything which might remind people of that, regardless of whether it was justified or not.

Canada had been pressing the US to make some sort of "deal". Trump however was not willing to accommodate him, although Trump's offer to China to release Meng in return for a good trade deal would likely by itself have provided grounds for Canada to refuse extradition at a later point in the process.

However, Trump was gone, and Biden was apparently more willing to be accommodating to Canada and so a deal was finally done. It was widely suspected that this was a quid pro quo in return for Canada not making a fuss over the cancellation of the Keystone XL pipeline.

Windows on x86 is the new mainframe.

Apple has shown that it's possible to make an ARM CPU for PCs that has reasonable performance.

The issue with aiming for the Windows market is that the amount of third party software, especially business critical software, is far, far, larger for Windows than for Apple. And that x86 software is in running systems that are not easily replaced even if it is technically possible to port to ARM. Microsoft makes most of their Windows money from licensing and support contracts with businesses who are tied to x86 by all of this software.

Microsoft Windows on x86 is the new IBM mainframe. It may not be the future, but it's not going away any time soon, and it will continue to provide a steady cash stream to Microsoft.

Is this related to the recent problems with organized IT crime elsewhere in Asia?

It would be interesting to know if these are the notorious Chinese crime gangs that have been operating out of Myanmar (Burma) and Cambodia which have also been in the news recently.

These crime gangs have been running rampant across China, Hong Kong, and much of the rest of east and southeast Asia with telephone scams, cryptocurrency scams, and pretty much everything else that can be done remotely. They get workers from all across Asia (including India) by promising them well paid jobs in legitimate businesses and then holding them prisoner until they make enough money from scams to pay back a specified "debt".

Most of them seem to operate from free trade zones in Myanmar, with Cambodia being another major location, but they also have offices in places such as Dubai.

The Chinese government have been trying to get to grips with them by telling expats in certain countries to return home and provide evidence that they are engaged in legitimate business. If they refuse then their property in China will be seized and life will be made difficult for their families (e.g. cut off from government benefits). They seem to congregate in countries which don't extradite to China (either because of no treaty or because the legal system doesn't work).

The main problem seems to be that in Myanmar at least the crime gangs seem to operate under the protection of the Myanmar military who get a cut of the action. The main operating location is in a free trade zone across the border from China. I think the free trade zones (which also have legitimate businesses) get Internet connectivity via China and so have access to Chinese IT hosting services and the like through various cut-outs and fronts.

I don't know if the connection is there, but it occurs to me that it may not be a coincidence that the problems mentioned in India are occurring at the same time as the other problems across east and south Asia. I suspect that countries across Asia may need to cooperate to squash this problem or else it will just move around from legal haven to legal haven if countries act individually to try to squash individual manifestations of it.

Using AI to attribute anonymous texts to known authors is something that academics have been working on for years for historic texts. This in turn is an improvement on the older manual methods. A typical application would be for example to try to attribute an anonymous poem to a known author (e.g. Shakespeare, or one of the Greek classics).

If they are doing anything new in the project being described in the story, I suspect it will be in terms of trying to do this in a way which was more suitable for mass surveillance, or to try to do it in cases where the author was trying to conceal his writing style.

This last point, uncovering authors who were trying to conceal their style, may be why they are doing joint a anonymize/de-anonymize project. By pitting them against each other they can get ahead and stay ahead of the AI arms race when it comes to de-anonymizing people.

Not Impressed.

I can't comment on NPM, because I haven't used it, but I do have projects on PyPI. I had a look at the paper, and it's pretty clear that the "problems" listed are not in PyPI, but rather in Github.

To start with, they don't actually look at PyPI except to get a list of projects which they then look for on Github. There is no link between PyPI and Github. You can have packages in PyPI without having a Github account or any code in Github. They are two completely independent things.

Their scorecard is entirely based on the assumption that you do everything through Github and use all of it's workflow features. If you use Github just as a place to publish code for the public, then you will get a low score. If you use all the Github bells and whistles and use them the right way, then you get a high score.

In other words, part of the score is based on result, and part of it is based on "process". And by "process" they only mean is your process conducted in Github rather than somewhere else.

A good example is "maintained". If a project doesn't get at least one commit per week to Github, then it is is marked down. There's no reason why that should be a valid criteria. The project may not be unmaintained. It may simply be stable and isn't getting updates because there isn't anything wrong which needs fixing. Or you could be working away on new features, but Github is just where you publish the source code as opposed to the place where you actually work from.

This is why there are so many projects which score highly in terms of not having anything wrong, but most seem to have low scores in terms of making use of Github's automated work processes.

I have a Github account and I have packages in PyPI. Part of my work process is to push code to Github for source publishing and to upload packages to PyPI for users. I have my own testing and QA processes which I run on my own hardware as I have no intention of locking myself into Github. It's just a convenient place to host the source code for anyone who wants it. I have been planning to also push source to another Git repo aside from Github to reduce my dependency on them for some time, but I simply haven't got around to it yet.

Overall, I'm not impressed with the report.

P.S. "Standard" security mode (the most relaxed standard setting) in Firefox seems to give The Register fits and result in a page not found error. I can only post on this site by fiddling with the security settings and manually turning off tracking protection. I've no problems anywhere else. El Reg should get a "fail" on the testing and maintaining score card.

From what little I've been able to find out about it, the Centre for Development of Advanced Computing (CDAC) are the designers and VVDN are just the contract manufacturer. VVDN were selected as they have the necessary manufacturing facilities.

The Rudra supercomputer will use dual socket Intel CPU servers with GPU acceleration, and an interconnect system called "Trinetra".

The individual servers are intended to also be as the basis for conventional stand alone commercial servers. The intention seems to be more that of using the HPC project to help advance India's commercial server manufacturing capacity rather than trying to be at the bleeding edge of supercomputers.

In other worlds, it's part of their economic development program, and should be evaluated in light of that.

According to US financial sources, if ARM list in the US as their only listing they will need to move their headquarters to the US in order to qualify to be part of US indexes.

So, not listing in London probably guarantees an eventual move of the headquarters, and probably sooner rather than later.

It will also put ARM more firmly under US legal jurisdiction, which in turn will cause many of their non-US licensees to elevate their RISC-V contingency plans to priority one for anything not locked into Google or Apple.

In other words, it would be the start of a long, slow. death of ARM in terms of any British connection.

Has been a problem for decades.

This sort of thing has been very common with industrial control software for at least 20 years that I can recall. Downloads of password crackers and cracked versions of (otherwise very expensive) copy protected programming software has been widely known to generally come full of all sorts of malware.

That anybody would fall for this shows if anything the naivety of the targets.

The main reasons for needing password crackers by the way are:

• Someone left the company on bad terms and put a password on some of the PLCs as a parting gift.
• The project engineering department has a "toss the project over the transom" relationship with the maintenance department, and any drawings, passwords, and backups the latter received were not "as built".
• The company bought some used machinery, and anybody who may have known what the password was is long out of the picture.

The above doesn't cover every reason, but it probably covers 99 per cent of cases.

Fortunately, passwords are only very rarely used on PLCs, as there's seldom any point to them. Out of many hundreds of PLCs that I've worked with, I can't recall seeing a password on any of them.

Any access control is usually handled by the fact that you typically need physical access to the PLC, a copy of the programming software, and a knowledge of how to use all of this in order to do anything with it. Some programming software uses access control passwords as part of the software rather than in the PLC itself.

Someone who was really determined to change the program in a PLC and had the physical access to it could just wipe the memory and reload a new copy of the program reconstructed from printouts.

Incebe-cert Error

The Incebe-cert article referenced in the story has a rather glaring error in its description of Modbus/TCP.

"Change from master/slave to client/server. According to the new specification, Modbus devices will now no longer be the master and the slave, rather it will change to a more computer language and therefore they are called client and server. The client would correspond to the traditional master and the server would be the final device, previously called slave."

The Modbus/TCP spec already uses client/server rather than master/slave and has done so from the beginning. I just checked my copy of the spec (2006 edition) and it says client/sever.

The reason that client/server was adopted as the terminology was to make it compliant with the terminology used by TCP, which in turn came from the analogy of a restaurant waiter and diners (server and clients) used in the IT industry to reflect the network configuration used there, where one server would have many clients. In an industrial network one client would have many servers (hence the master/slave analogy used)

Since the intention was to simply adopt office IT technologies wholesale instead of re-inventing them, the client/server terminology came with it.

The Modbus organization themselves have published a security specification which is referenced in the inciebe-cert article. Inciebe-cert seem to understand normal computer security, but they're clearly not that familiar with Modbus itself.

I suspect that the main market for the first RISC-V laptop is going to be software developers who want a native platform on which to test and debug the software needed to help create the second RISC-V laptop.

I tried to have a look at the actual report. The publicly available information is so vague as to be totally meaningless. Actual details are only available to members.

The one example they did make at least vague reference to sounded like an oil tank farm. This is such a niche and atypical industrial application that it provides no guide to whether their concept has wider application in industry.

There are existing wireless industrial applications, but they tend to be either things like remote access to installations that are scattered over a wide area (e.g. tank farms, water or petroleum well sites, etc.), or mobile applications (lift trucks in places such as warehouses, mine vehicles, etc.).

Moving from what are often bespoke and proprietary wireless systems to some new industry standard may have some advantages, but it's far from a game changer in industry overall.

Installation Time

Just as a data point, I decided to just now time how long it takes to install Linux in a VirtualBox VM. I picked Ubuntu 20.04 as that was what I had on hand. I turned off the VM's network connection so that the test didn't include time to download updates (which would depend on connection speed). I used the default installation options. The VM was running on a PC with an SSD.

Installation mainly consisted of giving it a user name and password, selecting time zone from a map, and clicking on "continue" to accept the defaults for everything else.

From the time I clicked on "start" to boot the VM until it was fully installed, including the default set of applications, and rebooted (one reboot), was 10 minutes and 8 seconds.