oldandtired

I have watched this dispute for many decades and the reality is that there is ebb and flow in the lifecycle of such things. The biggest problem is that people do not have sound memories of what has happened in the past.

The Great Barrier Reef is a good example of the dire calls about its impending destruction. As far as the [experts] of James Cook University are concerned, I have serious doubts as to the abilities of the researchers there. Far too much politicing going on.

Because it affects them more, the locals are more involved in caring for such without the interference of the [experts] who make their [expert] claims. The locals know just how silly many of these claims are and are now in the habit of not informing the [experts] so that the actual environments are protected.

Certainly. My middle son was looking at buying a property in a near by town. He asked me to come an look at it. We had the actual shire plans for the blocks and while looking at the property lines, we measured the actual fence to fence widths. The block was being sold by the owner of an adjoining block and when we measured we found that the fence line had been moved by about 20 to 30 cm. On querying the owner about this, he was somewhat angry that we were questioning where the fence was as he was the one who had it built.

From what I could see, the builders most likely kicked the boundary peg out of the ground and just put it back willy nilly.

As a consequence, I did advise my son to have nothing to do with the property and we did inform the real estate agent of the problem. This would put legal responsibility on the estate agent if it was sold without the boundary line being corrected.

Due diligence is necessary if you are doing this kind of thing.

This scenario happens far more often than most people realise, putting up a building on the wrong plot of land. If you are not going to do your due diligence then you will suffer the consequences.

If you build on the wrong plot, the only person to blame is yourself.

I didn't think my play on words would cause such controversy about acceleration and jerk. Mayhaps I should not be making "Dad jokes" here.

Here in Victoria (Australia), we commonly see road signs stating that "speed kills" whereas the reality is that it is the jerk that kills.

One of the basic causes for slowness is how the underlying language implementation does procedure calls.

Decades ago, I looked at how Microsoft handled procedure calls and returns of data. I found the same problem elsewhere.

The problem was related to copying of data. A single API call could involve (at the time) up to 100's of copy actions of the same value for each subsequent internal call. The actual processing of that data was minimal in the scheme of things.

This has been a problem amongst many others over the decades and will continue to be so for the foreseeable future.

Things that we did as a matter of course when resources were restricted have been dispensed with once those resource limits were exceeded. The lessons have subsequently been forgotten.

Far too many people (including AI researchers themselves) fail to see that all LLMs are actually simple machines. Extremely simple machines that are only mechanically following a relatively simple programming path.

Now before anyone gets too caught up with objecting to this notion, I would seriously suggest that you spend time with observing children from new-born to 2 years.

I have been observing my latest granddaughter sine her birth about 16 months ago and thinking about every public LLM system current;y available.

There is an insight here to be obtained and that insight is in the nature of real intelligence.

On the whole, no-one actually knows what intelligence is or what sentience is or what it means to be cognitively conscious. There is still much research going on and nothing actually definitive has come forth yet. We really are at the beginning in terms of studying these areas.

We can certainly produce some incredible systems, but none of them are intelligent per se. Solutions to certain kinds of problems can be achieved using these systems and there are researchers who are seriously looking at incorporating these systems into CAS and theorem provers. These systems though only provide an augmentation service for a person as does every mechanical system we use

But there is an essential component necessary for the use of all LLMs which many seem to not be cognisant of and that is these systems, to be useful, require humans to be involved.

The questions we have to ask ourselves is: what can we use these systems for and do these uses provide benefits in some way or can these systems be abused by various parties in obtaining control over others?

There are benefits and there are abuses. Can we do better or will we do worse by using them?

For the duration of their incarceration, why is there an expectation that those incarcerated have a right to vote anyway. Of course there are people who are in prison who shouldn't be and there are those not in prison who should be (including many politicians).

In a relatively ideal (of course there is none) world, those who have basically abused the citizens of an area should not have a say in the politics of that area that then affect the citizens of that area.

Once those incarcerated have paid their dues and served their time, they become eligible to partake again as citizens and should have the same voting rights as anyone else.

Over 40 years, I have seen many "programmers" who should never been in the business. Some of these were marketed as "guru" programmers. I suppose such idiotic systems like ChatGPT and its ilk could replace some of these.

However, anyone who has had to build the required skills to actively get real work done will probably find that they will not be replaced by such systems in terms of skill replacement.

What is more likely to happen is that the pointy heads in upper management will replace them because of the usual lack of foresight and intelligence on the part of the pointy heads.

So, yes, all sorts of programmers will be replaced by these systems and we shall see the systems produced become more garbage faster than we have already seen.

Doesn't support Linux though or any of the unixes. Looks good though.

Your third option is never good.

Not cowering before bullies, even if you have been beaten up works wonders. So does ignoring the tom fools.

Their goal to intimidate and make you fearful has failed at this point and it becomes far more problematic for them and their egos.

Private school has a different kind of bully.

Says it all.

If you want pristine sand beaches then expect major change over time. Looking at areas where there is little change over time, certain coastal structures are in plain sight.

But as many have already noted, the sea erodes all coastlines. However, what the sea takes away at one time, it also brings back in another time. When my father was in his teens, the water's edge for a small residential site was over a mile away. By the time I was in my teens, that distance had been reduced to 30 metres. By the time I was in my late twenties and early thirties, the water's edge was now at half a kilometre further out. Since then (I'm in the mid 60's) that beach has has grown and receded a couple more times.

Moral of the story, build only where there is relatively constant conditions.

As I wrote above:

> The reality is that it is based on a very distorted view of relational algebra as in it is based on tables, which are not relations but bags of records. It allows nulls to represents all sorts of information and the nulls are not treated in any uniform way.

Very simply, relations are sets and sets do not have duplicate elements. SQL tables are effectively bags, where duplicates are allowed.

The only reason you see unique elements in tables is that in implementations you can define primary keys, which forces uniqueness. If there is no primary key defined then you can add as many copies as you want of any record and the system doesn't care. The default for a relation is that the primary key is every field within the entire tuple, you do not have to define a primary key as the RDBMS does that automatically for you. No duplicates can occur.

The other aspect is that nulls do not occur. The interesting thing is this forces you to design your relations carefully so that you do not have nulls occurring. You will find that there are various people who hold contra views about this and you have to look at the subject and make up your own mind. Personally, I have found that proper design and removal of nulls brings a high efficiency to the resultant database.

One lesson learnt over decades of database design and system development using SQL and SQL DBMS's, is that you have to be extremely careful in your design. I have had to redesign poorly thought out databases that had been built by those who had not put in the time and effort to understand what relational algebra meant. I spent years learning the subject and still didn't delve into the extensive depths of the subject.

Relation database theory stemmed from Codd's original papers, which you should be able to download. But this was only the start of the theory related to this subject. Various developments occurred over the next few decades. You also had various people argue against relational algebra as a useful device for creating databases.

SQL databases and DBMS were supposed to be designed on Codd's papers but essentially didn't succeed, thus leading to the mess we see today.

There have also been various personality clashes in the field, which have lead to various controversies about database technology. I simply avoided that side of things wherever I could as they were not relevant to solving the problem space problems that I was tasked to solve. There are various well-known people who proselytise their particular views about database technologies and dismiss other opposing technologies. There have been various proposals to solve the problems being faced and the reality is that for any problem you have, it is up to you to choose what works effectively for you.

If I am going to use a database as part of the solution, I still design based on relational theory as this to me is the better option. Your situation will be different and you can choose whatever is appropriate for you. However, it is beneficial to delve into relational theory as it will give you alternative ideas to play with. There is plenty of resources out there that will show you both good and bad ideas in designing any database.

My choice of DBMS is PostgreSQL and it suite of tools. I would personally stay away from Microsoft and Oracle as I have had various issues (not problems but serious issues) with each of these besides being payware. There are others like SQLite, etc which appear to be useful for small systems on the basis of feedback of other people I know. I don't have any experience in the large with these and so cannot comment on the effectiveness of these systems.

Mind you, I have been out of the thick of it for a decade or so as I am effectively retired, even though I still actively do projects I am interested in when I feel like doing such work.