Re: "I wonder if someone... might use this to sue Microsoft under the Trades Descriptions Act."
"and widely reported."
But no widely reported contradiction. But never mind: plausible deniability.
40413 publicly visible posts • joined 16 Jun 2014
"Companies will not spend man-hours to upgrade and retrain"
If you want a UI that doesn't require periodic retraining of users - nor requires them to just take UI changes in their stride without retraining - then you're a lot better off moving to Linux.
Do the retraining once and from then on enjoy the stability of UI. Between KDE 3 & KDE 5 there's only been one change that's really annoyed me and that's the fact that I can no longer confine un-hide of the panel (task bar to you) to a corner. I suppose for Windows users that would be classed as a minor annoyance given what Microsoft have wrought on them over that time.
Unfortunately a few applications, particularly browsers have changed their UI for the worse. That's because they've followed what happens on Windows and, believe me, that imported lack of stability bugs me no end.
" It was supposed to be the last version until Redmond got an aneurysm and decided to do another one."
I wonder if someone faced with a large, otherwise unnecessary, replacement requirement might use this to sue Microsoft under the Trades Descriptions Act.
"it's seventy three competing GUIs"
You say that like it's a bad thing. But one size does not fit all. Liam reviewed Elementary here the other day. I'm sure it has users who find it to be just what they want, likewise Cinnamon, XFCE, Gnome, Unity or whatever. If I personally find KDE fits my way of doing things then I don't have to use any of the others (a couple of which would be an extremely bad fit for me).
To take just one aspect of it - the versions of Windows from 95 to 2000 had a fairly configurable and on the whole user-friendly hierarchical start menu organised on more or less functional lines. Over the years since it has changed into what appears to be an inflexible lumpen mess ending up resorting to alphabetical ordering because nobody seems to recognise that functional organisation is what's needed. I understand that many users resort to typing the name of the program they want into search - they've reinvented the command line in desperation. The Linux desktops I've used have retained the functional organisation and improved on it. KDE, the one I'm most familiar with is fully editable to achieve the arrangement that best suits the user and has remained that way as long as I've used it and has also sprouted a couple of extra choices as to how the user wishes to view the menu.
It's a world away from the Windows approach of use this whether it works well for you or not, until the next one which might work in an entirely different way. I can have something I can tailor to my needs and enjoy consistency of UI from one release to the next.
That choice of desktops isn't a reason to avoid Linux - it's actually a very good reason to use it.
The desktops are over a clone of a 50 year old minicomputer operating system? Fine, there were some very clever people about 50 years ago. Even back then I preferred the one that was cloned for Linux over the one that was cloned for Windows.
Over the past few year or so my wife's cardiac and, particularly the last few weeks, blood pressure problems - together with a few of my own have given me chance to observe the local hospital trust and especially the local A&E.
Firstly they do have a trust system. It has links to a national system so they can look up NHS number from name, DoB & post code (as can online booking for flu & covid jabs). The only connected printer in evidence at A&E reception spits out a wrist band with name, NHS number and a QR code. That solves the patient ID as they're moved around. BP testing devices have an RJ45 so presumably could be networked but aren't - it would probably be impractical - so readings have to be typed in but doctors and nurse practitioners can review what's been done. The cardiac ward in the other main hospital in the trust has hand-helds which look like smartphones but I suppose might not be which are used to register the readings. I'm not sure how the doctors review this on ward rounds but in the A&E offices they can review everything without needing a paper record. On the face of it it appears that this trust is largely if not entirely paperless apart from the wrist bands, at least on a functional level although it's possible there might be a paper back-up. I don't know the origins of the system but I doubt it's written in house; it will be bought in.
Our GP also has a practice system so they also are largely if not entirely paperless, at least on a functional level. I know this is system is bought in, in fact I'm pretty sure it runs on the provider's server.
The need for paper, then, seems to be communicating between trust and GP and possibly between trusts (SWMBO was sent elsewhere for a TAVI last year). This set me thinking: bearing in mind that perfection is the enemy of the good, let alone the workable, is it possible to build a bottom-up system instead of some grand plan, especially one to be handed over to a major data-broker? How does email work, or the web, or any effective communications system? It has scarcely any central requirement other than data standards - communication protocols and defined message formats and a hierarchical, distributed registry. There's no need for everyone to use a specific client. There's no need for MSPs to use the same server software. Providing the clients and servers follow the protocols and handle the same message format everything works. It should be possible to build something on those principles.
A quick online search shows that there's a lot of information about medical exchange message formats. Pick one, preferably one that's extensible. Specify a core amount of information and a go-live date. It doesn't matter how different the internal databases of the various providers are, all they have to do is to provide an interface to read or write that subset of data to that format. Now we have to decide how to exchange data about the patient. As the system evolves extensions for extra data can be defined and added in phases.
On the basis that the patient is registered with a GP (not all patients may be but let's start with what's practical) the GP (in practice the GP's service provider) is the obvious place to exchange information; it's the GP who will refer patients a lot of the time and even if a hospital trust encounters the patient as an A&E walk in the GP will need to know eventually. Clearly a network is needed to transmit messages securely and I'm assuming that NHS.net can provide this and that most, if not all, trusts and GPs have NHS.net addresses. Again "most" can be the starting point.
What the network needs to provide is a central registry to provide identify the patient's GP and I'd be somewhat surprised if the system which already provides the lookup for NHS number didn't already include this; and a store and forward message handling system which looks remarkably like email. It may well be that the GP service providers could handle the latter
TL;DR A system could be built bottom up. No massive central contract is needed. Software would be an add-on to existing medical record systems by the providers of those systems. Not every patient nor every possible item of data might be served by this but the system could start earning its keep from go-live and grow out from there. Perfection is the enemy of the workable.
Primarily it was a wrist-mounted display object whose prime function was to show, by having been purchased, what the owner could afford to by. Having been purchased and flashed about most of its utility value has been used up. Being a wrist-mounted gadget that could also tell you the time was its residual utility value (plus the melt price of the gold, of course).
I don't think many people in Kirklees think it works. It was a cobbling together of areas which previously had their own administrations with the West Riding County Council on top of them. The name was presumably the consequence of there being no name within the combined area which wouldn't identify it with one of the original areas to the detriment of the other. It's not a bit of accidental daftness - it reflects the underlying lack of logic.
I suppose the destabilising factor was breaking up the WRCC to create the Peoples Republic of South Yorkshire. That, of course, is the root of your Whitby/Settle issue - Settle was also part of the West Riding.
Now, for goodness sake, we've also got a West Yorkshire mayor to no obvious purpose.
Given that there are raster and vactor editors to learn from those aren't to trick parts of the puzzle. The bit that requires imagination is how to produce a workable paint program from it. I'd like to think that if you put that problem as a test the human would start by thinking what the interface would have to look like but what would a ML do?
A better test would be to provide it with a problem for which there is currently no solution although it should not be impossible to produce one.
For instance the open Document Foundation define a format with the file extension .odi as an image format. As far as I can follow it's a multilayered format in the same manner as, say .ora but can include SVG as well as PNG layers. Produce a paint application to generate, display and edit files which contain arbitrary arrangements layers of both types with variable levels of transparency in each layer..
It should be possible but as far as I know nobody has produced on so there is no prior art to regurgitate. Imagining and realising a good solution to a novel problem is what distinguishes a developer from a coder.
"the concrete absorbing CO2"
Quite. Calcium really does want to become the carbonate so most if not all the CO2 is absorbed in the long run - except what's released by burning the fuel to produce the energy to drive off the original CO2. This is why I get a bit sceptical about solutions that depend on using some form of calcium to absorb CO2. There's one which involved using it as a sort of middle man to absorb CO2 from chimneys, then heating it to drive it off again for sub-sea storage. But what's the overall efficiency if it depends on a fossil fuel for the heat? And if there's some sort of renewable energy for the heating why wasn't that used instead of whatever required the chimneys? You need to look at the complete system.
US Geography is not by strong point but I don't think Boulder, Colorado is near the sea. That raises the question of where the calcium in this "biogenic" limestone comes from. If it's from non-carbonate sources such as gypsum that's fine but if it's obtained by treatment of limestone that releases CO2 then it's not a gain.
"Biogenic" limestone in quotes because all limestone is biogenic.