ryao

The Chernobyl plant had known construction defects that could impair safety. These things would prevent a western plant from starting operation, but did not stop the Soviet plant from beginning operation:

https://inspectapedia.com/structure/Chernobyl_Nuclear_Disast...

They did not even have any automated safeties in place, because their philosophy was “faith in the worker” while the western philosophy is “humans are fallible”:

https://www.eit.edu.au/engineering-failures-chernobyl-disast...

They then ignored their own safety procedures when operating the plant, which ultimately is what caused the disaster.

Saying that Soviet designs being in the same generation as western designs makes them equally safe/unsafe is quite wrong when you look at the details. The Chernobyl nuclear power plant was one mistake after another.

That said, the plant was designed by a country that shot down a civilian airliner that had strayed into their airspace due to a navigational error, when they knew it was a civilian airliner:

https://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007

They had no regard for human life, so of course, they built things that are incredibly unsafe. There is no end of examples of them simply not caring about human life.

Why mine uranium? Only about 4% of nuclear fuel is actually used before the fuel rods need replacement, which makes uranium highly recyclable. Given all of the “spent” fuel rods in storage, mining operations for additional uranium are unnecessary. We have enough uranium to supply our energy needs for millennia, provided we are willing to begin a recycling program.

Interestingly, the 4% actual “waste” is also quite valuable for industrial, scientific and medical purposes too. Radiation treatments for cancer, X-ray machines, etcetera all can use isotopes from it. This is not mentioning smoke detectors, betavoltaics and the numerous other useful things that can be made out of them. Deep space missions by NASA rely on betavoltaic power sources. Currently, there is a shortage, which has resulted in various missions being cancelled. Our failure to recycle “spent” nuclear fuel rods is a wasted opportunity.

Data reported by Forbes put the death rates for nuclear power in the US below all other sources of energy including solar:

https://www.forbes.com/sites/jamesconca/2012/06/10/energys-d...

The death rates are wildly different than the ones at the site you linked. I wonder what the reason is for the discrepancy.

I do not plan to try this but I do wonder how well the terminal version of WordPerfect would work in this.

Also, if sixel support were added, it could support graphics. See:

https://github.com/taviso/wpunix/wiki/Terminals

If sixels somehow are already supported, then it does support graphics.

Ask someone who is visually impaired. I know that they historically use browsers that do not support JavaScript. I also am acquainted with one developer who uses software for reading his terminal outloud, although I never asked the specifics of what he uses for web browsing or IRC for that matter. I do know that he loves the iPhone.

That said, I just found this post by a blind person who uses Lynx and complained about it the last time Google broke Lynx support:

https://blind.guru/blog/2019-11-25-endofgoogle.html

I suspect X11 can do mixed DPI and VRR with multiple displays if you do 1 display per xscreen, but nobody uses that configuration.

I suspect HDR support could be added if someone were to retrofit it like how VR support was added, but no one really wants to work on that.

It sounds like how ChromeOS is Gentoo based but does not ship the package manager.

I wonder to what extent visually disabled internet users are affected by this, since I can imagine at least some of them using lynx with an on-screen reader for a terminal emulator.

I thought that he said that they gave up at competing with Nvidia at training, not in general. He left the door open to compete on inference. Did he say otherwise more recently?

I half expected to read that he devised a charging circuit for it controlled by a raspberry pi. I was somewhat disappointed when it turned out to be a normal blog post about buying a car.

In that case, this was one of the most expensive no-ops in history.

If it allowed them to move faster than their completion, I imagine management would consider it money well spent. They are expected to spend absurd amounts of money to get ahead. They were never expected to spend money efficiently if it meant taking additional months/years to get results.

The article author is wrong. It happens. Draw a vent diagram with two partially overlapping circles. You and the author are looking at the overlap and concluding the two are the same. They are not, given the stuff outside the overlap.

As for the one distinction you recognize and think is invalid, that distinction is given by the definition you found. You refuse to obey the definition you yourself quoted to settle matter elsewhere in the thread.

You can use similar logic to declare English to be an example of Chinese. They both have syllables. They both assemble syllables into words that convey meaning. They both use grammars to form relationships between those words. Thus, they must be the same. It is fallacious logic. Some similarities do not make things the same. Data abstraction is also its own topic that is able to stand independently from OOP. What the kernel does is data abstraction, not OOP. What you are seeing in the kernel are the abstract data types of data abstraction.

I have no idea what LWN post you mean. You can make stubs trap by doing a NULL function pointer dereference, but that does not make NULL function pointer dereferences the same as stubs in general.

You would typically put the this pointer into the first argument when doing OOP in C. You can put the this pointer in the last argument to have it work too. However, you cannot omit it entirely. That is something that is not OOP. It is an ADT.

If you leave out the this pointer, it is the equivalent of putting a function pointer to a global function (or a static member function) into the structure. This is not how OOP works.

Omitting the this pointer also breaks inheritance, since hypothetical child classes would not be able to override the definition while using the this pointer. Having to edit the parent class to be able to do that is not how OOP works.

This is not OOP nor is it intended to be.

It cannot be overridden by subclasses without risking undefined behavior because there is no this pointer for it to use.

The point of a vtable is to implement virtual member functions that support inheritance and polymorphism without changing the base class implementations no matter what the child classes do. If you omit the this pointer, you cannot do inheritance that uses the this pointer in an override without changing the implementation of the parent to add the this pointer back, which would be like a tail wagging a dog. Thus, it is not a vtable. It is something similar, but different.

> Yes. Since we are not in C++ we can choose to get rid of this useless pointer.

If you were trying to implement OOP in the kernel in C and implemented a vtable, you cannot get rid of the this pointer in vtable entries since a child class might want to use it in the overrode definition. It is one of the same reasons why you cannot remove it in C++. The entire point of a vtable is to enable inheritance. If OOP really were being done, an out of tree module could make a class that inherits from this one without needing any code changes and use the this pointer, but you cannot do that if you drop the this pointer. I already explained this.

You don’t implement calls to static member functions by putting them into a vtable, which is one of many reasons why this is not a vtable. The proper way to implement static functions is through static dispatch.

I never said that the type was known before runtime in OO. Your not a bug comment sounds awfully like an all bugs are features. Implementing static member functions this way would cause undefined behavior, which is a bug.

It is not the same theory, since it is an ADT, not anything object oriented. Different theories can and do overlap. The emitted code is also not the same, since there is no implicit this pointer. You are the one who posted a definition you found and then claimed that it agreed with you, when it did not and now are reneging on your use of it. You do not understand this topic as well as you think you do and this is a silly hill to die on.

A stub is an empty implementation. An empty implementation is different from no implementation, where there is no code to execute. It is the difference between writing 0 and writing nothing.

Data abstraction is a separate invention from OOP since it involves abstract data types. What is being used here is an abstract data type. It is not the pattern used in OOP languages and it is not OOP. It bears similarities and overlap with the vtables used to implement some OOP languages. It is like how thumbs bear similarities and overlap with index fingers, but the two are not the same.

If the kernel were written in C++, it would still be done the way it is done now. C++ does not allow unimplemented member functions and the ADTs currently used do. You can emulate that with multiple inheritance, but it is an inferior way of doing this.

As I said, these are NOT vtables. The fact that you and some others keep thinking of them as vtables misleads you into thinking that this can be done using the object oriented tools of C++. It cannot without major hacks and the result would be slower, harder to read and only something that a bureaucrat could like.

The calling convention for C++ non-static member functions always includes a this pointer, even if the function does not use it. Removing it on member functions that do not use it would pose a problem if another class inherited from this class and overrode the function definition with one that did use it. Maybe in very special cases whole program optimization could safely remove the this pointer, but it is questionable whether any compiler author would go through the trouble given that the exception handling would need to know about the change. Outside of whole program optimization, it is unlikely removing this from member functions that do not use it would ever happen because it would break ABI stability.

As for how inheritance works when the member function is not in the vtable, that depends on what kind of member function it is. All C++ functions are given a mangled name that is stuffed into C’s infrastructure for linking symbols. For static member functions, inheritance is irrelevant since they are tied to the class. Calls to static member functions go directly to the mangled function with no indirections, just as if it had been a global function. For non-static virtual member functions, you use the vtable pointer to find it. For non-virtual member functions, the call goes straight to the function as if a global function had been called (and the this pointer is still passed, even if the function does not use it), since the compiler knows the type and thus can tell the linker to have calls there go to the function through the appropriately mangled name. It is just like calling a global function.

The definition you quoted requires the language to be the one doing it for it to be a vtable. If the programmer is doing it, then it is not a vtable by that definition.

There is always a subset of the population for which it is fashionable to try to make a new language to make things easier. It is inevitable that someone in a sufficiently large organization will try to make one, provided management supports it. Apple is a very wealthy company that is happy to sponsor R&D, had someone interested in this that they sponsored and the result was appealing enough that they decided to adopt it.

That is my understanding of how the process generally works and what I am willing to guess happened. Prior to this, they had been making incremental changes to Objective-C.

That said, from what I have seen of the syntax of both languages, swift’s syntax is nicer and that is not something that they would have been able to get from Objective-C. They already had tried syntax reform for Objective-C once in the past and abandoned it.

Let’s say I have ClassA::Foobar() and ClassB::Foobar(), and ClassB inherits from ClassA. Now let’s say I want to use ClassA::Foobar(), and I access it from the object because this pointer is in the vtable and the object is of type ClassB. Now ClassB::Foobar() executed, which is wrong. This is why static functions are not put into vtables. What Linux is doing is not a vtable, even if it shares similarities. Perhaps you would understand this if I said all thumbs are fingers, but not all fingers are thumbs.