A Review for The Prince by Niccolo Machiavelli

I have read “The Prince” by Niccolo Machiavelli. Feel free to read my review.

A short review on “Professional CMake” by Craig Scott.

I have read “Professional CMake” by Craig Scott. This is short review. This time the review is, indeed, going to be short, because I cannot really say that the book was a paradigm-changing read. Nevertheless, I have decided to make reviews on most books I read, and this one is not an exception.

A review on “Little Soldiers” by Lenora Chu.

I have gone through the book in the title. I am no saying “have read”, because for quite some time already, since first grasping this trick while conquering Baudrillard’s “Simulacra”, I am getting through a lot of material via listening to Text-to-Speech, rather than reading directly. Not just is it very handy when there is a “sunken” time during which it is not possible to execute tasks that require full concentration. This, however, comes at a price, namely, certain details are perceived differently, compared to reading in a traditional way.

Anyway, I have listened through the book, and it was an enlightening experience, which I would like to share with the world in this short review.

The book tells a story of an American couple with two children living in Shanghai for a few years, who’s elder son had a chance to attend classes in a Chinese kindergarten (as opposed to what typically happens to the expat children in China – they attend foreign-style kindergartens, which are especially plentiful in Shanghai).

The book was especially interesting to me, as I am not an original product of either American, or Chinese culture, so I had a chance to see the story from a third-party perspective.

Musings on “The Force of Non-Violence” by Judith Butler (2020).

The Force of Non-Violence by Judith Butler (2020)

A long, confusing, self-inconsistent and contradictory “review” is following.

A short review of the “Art of War for Women” by Chin-Ning Choo.

The Art of War.

NOTE: this review is not about a similarly-titled book by Sheetz-Runkle, and not about a similarly-titled book by Huang and Rosenberg.

The “Art of War”, not such a long time ago used to be fairly unknown to the western audience. Maybe because there had already been a well-established western military tradition, represented by von Clausewitz. The Soviets, however, perhaps due to being actively involved with Asia since the very establishment, were much more open to the Eastern tradition, and the Art of War was a part of the Soviet intelligence curriculum for a long time. Eventually the West has also fallen victim to this millennia-old book on strategy and tactics, and the Art of War began its triumphant parade over the business culture. This was also partly fuelled by the very visible progress that the Asian cultures, from Mongolia to Japan, had by the end of the 20th century. One of the most prominent marks of the era was a recent British independence slogan “Will the Brexit Referendum make London the Singapore-on-Thames?”. Such an astonishing claim to be made in the former capital of the world.

The book by Ms Choo introduces the concept of the 21st century being the “Century of Asia” at the very beginning of the book. Indeed, although the book is full of citations from the Art of War, my feeling was that they were cherry-picked with the main purpose of adding Ms Choo’s book an Asian flavour, rather being the core knowledge carrier.

Maybe it’s actually for the best. To each his own, I am still planning to lay my hands on the old book itself, and thankfully, the “for Women” version was not much of a spoiler.

The second claim that is firmly made in the book is that the 21st century is going to be the century of women. That’s probably a thing that nobody is going to argue against, since the technology is making the world a much more comfortable place for women, so even though I would be more careful about attributing the whole century to just a since human trait (sex), we are definitely going (in fact we already are) seeing more female influence on the everyday life.

The core ideas.

The book is roughly structured around five aspects of success.

They bear fancy Chinese names, but for simplicity I am just writing them out in layman terms:

• Personal qualities
• Temporal properties
• Fixed properties
• Skill
• Implementation

Each chapter is dedicated to one of the components of success, and in each of those the author tries, beyond presenting the basic concept of a component and the actions that are needed to nurture this component, some additional traits that are supposed to be more related to women than men.

Quite unsurprisingly, as the book progresses, each subsequent chapter bears less “femaleness” and more “practical guidelines”.

In general, I cannot say that I highly assess the parts that are more dedicated to the sexual dimorphism. The management chapters were quite good. I have made a lot of records, and rearranged some of my working practices, following her advice. The “female” parts, to be honest, did not help illuminating how exactly sexual dimorphism affects the differences of performance between the employees of different sexes too much. The book contains quite a lot of female encouragement and debunking of old misconceptions about women, which is a great thing, but seems to be of less use to those who have already given up those misconceptions. However, developing “conceptions” (pun intended), that is the understanding when and how exactly sexual differences can be used as a leverage, and where they should be kept in mind as a thing of concern, is sub-optimal, in my opinion.

Conclusion

The book is short, and can be done in a couple of evenings. It is probably worth reading as an encouraging material, although women who have already decided to be the best of themselves, are unlikely to need any more encouragement. Some anecdotal evidence is nice, it feels very nice to be able to relate yourself to some real-life examples. Some paragons of female success are also given, from various areas of life, from politicians to doctors and managers. The management-related, gender-agnostic chapters are just good and worth looking even more than once. Is it the book to be read to find out about gender differences and how to use them – perhaps not, and it is also not a good book about the “Art of War”.

The main military thought that you can derive from it is that avoiding defeat may be often a much more efficient strategy than winning a battle. After all, Suvorov is believed to be emphasising this a lot.

The Russian translation is horrible, however.

Contacts

Subscribe and donate if you find anything in this blog and/or other pages useful. Repost, share and discuss, feedback helps me become better.

I also have:

Facebook

http://facebook.com/vladimir.nikishkin

Telegram

http://t.me/unobvious

GitLab

http://gitlab.com/lockywolf

Twitter

https://twitter.com/VANikishkin

PayPal

https://paypal.me/independentresearch

A Review on The Light That Failed by Ivan Krastev and Stephen Holmes

I have read “A Light That Failed”. This review is not a part of the series of reviews on technological books. Nevertheless, in order for a brain to keep moving, some humanitarian reading is advised.

This book was a part of a book club in discussion in Shanghai. Speaking briefly, it discusses the new (2019) tendency in politics in which the western politicians start using the rhetoric that they have not been using so far; the rhetoric that is not unlike the one used by the authoritarian politicians. Surprisingly, the book is known among readers in China, it has a rating on DouBan. The book is not related (at least, directly) to the eponymous novel by Rudyard Kipling. The book is not related (at least, directly) to the eponymous film of 1939, based on the work by Rudyard Kipling.

A Review for GNU Autotools by John Calcote (1st. ed.)

/ I saw a book titled ≪Die GNU Autotools≫ and I thought “My feelings exactly”. Turns out the book was in German. – Tim Martin./

I have read the GNU Autotools: A Practitioner’s Guide by John Calcote.

This is a small review of mine. This time the review is really small, mainly because there already is a good review, written by Flameeyes  https://flameeyes.blog/2010/08/20/book-review-autotools-by-john-calcote/, and even though ther review was arranged by the original publisher, No Starch Press , it is technically accurate and psychologically unbiased.

What I do have to add are just a few of my own experiences.

Russian kids are not taught a proper lesson in computer information exchange.

While this statement is a bit radical, most often there is not a single consice introductory lecture which would teach people how to make descent programs, and saying broader, software pakages out of scattered and disperse algorithms, which people are taught to create in high school and in universities.

Most people learn this by either struggling with Microsoft’s documentation, or (even worse) by copying existing Free Software projects, and tweaking the scripts.

This is a very bad approach.

I know, this is a very emotional statement. But my experience says the following: the less structured is the field you are studying, the more structure needs to be present withing the courses given.

As an example: C, C++, HTML, are reasonably well-structured topics. No matter how you approach the studying, there is only one definitive standard of those, and you have almost no chance of completing your tasks successfully unless you comply with the rules.

As an opposite example, creative writing is not that structured. Your literature teacher may give you good grades, or bad grades, but that would quite often be affected by his personal properties rather than his experiences with the audience you are targeting. In case of the high school class essays this doesn’t matter so much, because your target audience IS your teacher, but it gives you little expertise on how to write for other people.

Therefore, creative writing teaching should require much more elaborate courses than computer programming, exactly to overcome this uncertainty.

Making software packages is an ill-defined task.

You cannot ever solve it precisely. You can reach some level of closeness to the original goal, but as life evolves, your projects have no choice but to adapt to the changing world. Therefore creating software packages is a badly structured task

This makes it necessary to have a structured course. Calcote’s book provides such a course.

Indeed, despite being called “A practitioner’s guide.”, it is more of a good theory treatise than a cookbook. And this is good, not bad. Nowadays canned recipies are in abundace, at StackOverflow, for example. But well-narrated explanations are as rare as they have ever been.

Shall this book be studied at school.

No. Of course not. But it would be a very good idea to let university freshmen read this book as a part of their ‘practice of programming’ introductory classes.

Statistics

This book is 315 pages long, and required 29 hours 54 minutes of my time, including doing exersises and writing this review. This makes it roughly 10 pages per hour, 6 minutes per page. Those were produced in 11 study sessions, each session 2 to 4 hours, and was accomplished in one week, with more than one session per day on the weekend. The book was printed out on paper, and I was making annotations with a pencil. For practical text writing I was using GNU Emacs 26.2. In the

Bibliography

• Autotools Mythbuster
• Die GNU Autotools by Florian Stöhr
• No Starch Press’ webpage for the preview of the second edition
• GNU Website for Autoconf

Review for SSH Mastery by Michael W Lucas

Cover

Motivation

Why did I decide to read the SSH Mastery?

I have been using SSH for a long time, learning it bit by bit, intuitively. At some point I decided to arrange my knowledge in a more structured shape. So at that time I had a choice, whether to read official SSH documentation, or to look out for some external information, preferably from people who have experience of not just creating the product, but also of using it.

The problem with more prosaic books though is that they often risk just retelling the original documentation verbatim, which is always the safest choice, as all the errors may then be attributed to the software authors. On the other hand, they have a risk of falling into a terribly newbie- oriented, very verbose narration style, which would make them too voluminous for being digested in observable time.

Michael W Lucas’ book skilfully manages to avoid both of those pitfalls. It’s both concise and easily readable. Therefore, it didn’t take me too long time to print it out and dive into.

Why a book on SSH is even needed?

Indeed, why? What SSH even is? SSH stands for Secure SHell, but it actually has nothing to do with shells or cores. A ‘shell’ is just a name, traditionally used in computing to denote a way to ask a computer to perform exact tasks. That is, 90% of exact tasks are asking a computer to compute something. You know, that mode of your computer, when this huge 1000$ machine actually works as something it was designed to be 70 years ago: a huge calculator. (By inexact tasks I usually denote tasks which require automated, but not exactly computational tasks, such as calling your friends by a voice chat. )

When you use your calculator, you don’t really need any specific introduction into typing numbers, do you? Well, as I said, a personal computer is a very huge, and a very advanced calculator, so it needs a special advanced program to ask you for your formulae.

The word Secure here implies that using SSH, you can actually ask other computers to be the calculators you ask to compute something for you, and those only need to have the SSH on them, and be connected to a computer network.

So the main task of SSH is establishing connections to other calculators.

Is it so hard? Why would anyone have an extensive manual for a program which performs such a simple task?

There are many answers, but the main one is: not being obvious. The hardest thing to get used to when working with computers is that they are actually one of the least obvious things you find in this world, even less obvious than people.

It doesn’t mean that they are hard. Quite on the opposite, since computers are very dumb, and quite fast, if a good manual is available, few things are actually easier than computers.

But computers are painfully unobvious. Which image among the ones you see on your screen is a real one, and which one is a compressed one? No way to tell. Is the password you are typing on a website stored somewhere or is it not? Are you being attacked by hackers right at this moment, when you are reading this?

The answer to the last question is ‘yes’, even if you are not even remotely aware of the existence of those hackers. And they are also not even remotely aware about your existence, but they don’t even need to. They have robots do all the dirty work for them.

And this is also the place where official manuals fail to increase the obviousness of what is going on, as they are bound to only describing what a program should do, but not what the program should NOT do.

What is the book about?

SSH is usually used for connecting to a remote computer and giving it some orders using the command line.

One of the reasons for reading the book is learning that SSH can to much more than that. As I already said, it is very good at making any soft of connections between two machines.

A typical example: an SSH can work as a universal (so-called SOCKS5) proxy server between you browser and some computer in a country with a less outrageous censorship law. (Yes, to go around those nasty screens telling you that the government decided to block your access to some website.)

Or, SSH is able to forward just one connection from your computer to another computer. This may be very useful if your company is restricting websites which you are able to visit.

Yes, although this post is NOT about circumventing censorship, for non system administration people it’s not obvious (another picture on “not obvious”) that going around barriers is the very nature of computers.

Or, SSH is able to forward everything leaving your computer through a computer far away. Can be very useful if you company’s system administrator is collecting your bank card numbers for his own pleasure.

SSH can simplify a lot of cryptography for you, and the book is very practical about how to make your life as painless as possible while working with cryptography, and (if you never tried), cryptography is still a very very meticulous task, where every little bit helps.

Writing style

The SSH Mastery book is good at simply and in a concise manner explaining the (quite complicated) things. To be honest, I was astonished to see how many practical details Michael W Lucas managed to include in his book, and still keep it under 200 pages.

The book is enriched with practical examples from his own working experience, and he, besides being a writer, is one of the world’s best experts on secure operating systems. (He also wrote the Absolute BSD book.)

The book is also written in a swift, light, vocabulary-rich language. (Which is less surprising than it may seem, as Michael W Lucas is also writing fiction books(!).)

One of the best properties of the book is that it gives you the right tools to reach that sweet feeling of almightiness, which is one of the main reasons why people are choosing computers as a career. And this book makes this feeling not limited to just computing (or systems administration) professionals.

The book collection

Michael W Lucas is writing a series of books actually, under the shared name of ‘IT Mastery’. In this series he elaborates on those tools that systems administrators are learning by trial and error, and users often completely ignore, even though these are those tools which are actually controlling their lives and are used every day. All those have practical examples and accompanying life experience stories.

Should everyone read this book? Shall it be taught at school?

Well, I am sad to say no. Indeed, most people, most developers, and even most systems administrators can get by without ever consulting any reference material on SSH, and especially a prosaic book.

But saying that, most people can get by without so many things… Maybe it’s sometimes better to think in terms of enriching life, rather than surviving?

P.S.

Michael W. Lucas has no relation whatsoever to the film director Michael Lucas.

2019-07-04T10:25:13, Shanghai

GNU Emacs Manual 26.1

I have read the GNU Emacs manual. Before you turn away and switch to a
less propaganda-oriented topic, let me pledge that I’ll try to stick to only
speaking about the book itself, and its influence on me, rather than the
software it describes. This may sound a bit counter-intuitive, but I am
aiming at the audience slightly broader than purely operating systems
enthusiasts or even professional programmers. And as such, the book as a representation of a way of thinking would be more valuable than the actual
software itself.

A Mathematical Theory of Systems Engineering: The Elements by A. Wayne Wymore

The review on the book by Albert Wayne Wymore
‘A Mathematical Theory of Systems Engineering — The Elements’

This review must be prefaced with a quotation from the last chapter of the book, which is sort of really indicative of what you should expect from it if start reading.

“(Alan) Turing’s work is very important; there is no question about that. He illuminated many fundamental questions. In a sense, however, it is unfortunate that he chose to write in terms of ‘computability’ especially in view of development, subsequent to Turing’s work, of modern computers. As a theory of ‘computability’, Turing’s work is quite important, as a theory of ‘computations’, it is worthless.

“Wow!”, you would think. “This man has the audacity to defy Turing himself! He must be offering something really outstanding instead!”
Well, not really. What is then that he is offering instead?

To start reviewing a book about systems engineering, one would have to first, at least try to specify what systems engineering is. But even such a simple, supposedly, term would have to be met with caution. Well, obviously, it’s connected with the engineering of systems.

But if you open the definition of a system in the book, you’ll see the following:

A system is a set Z = {S, P, F, M, T, \sigma}, where 
    S is a set not empty,
    P is a set not empty,
    F is an admissible (ignore this word at the moment) set of input functions with values in P,
    M is a set of functions each defined on S with values in S,
    T is a subset of R containing 0,
    \sigma is a function defined on FxT with values in M such that \sigma is onto and 
        (1) the identity mapping \omega \in M and for every f \in F, \sigma(f,0) = \omega;
        (2) if f \in F, s, t, and s+t \in T, then \sigma(f -> s, t)\sigma(f,s) = \sigma(f, s+t);
        (3) if f and g \in F, s \in T, and f(t) = g(t) for all t \in R(s), then \sigma(f,s) = \sigma(g,s)

Wow. Looks really cryptic, doesn’t it?

Factually, if you open almost any other book on the subject, you’ll most probably see a completely different definition, likely dealing with loosely defined terms, such as ‘components’, ‘interfaces’, ‘actors’ and similar things from project management jargon.

For example, this is the definition of a system from the INCOSE’s Systems Engineer’s Handbook.

“… an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. (INCOSE)”

“Well”, you may tell me, “perhaps this Dr. Wymore is meaning something completely different?” Are they even speaking about the same field of knowledge?

Let’s check:

‘A. Wayne Wymore founded the first academic department of Systems Engineering in the world at the University of Arizona in 1960. He pioneered Mathematical-based Systems Engineering and later led Model-based Systems Engineering. He was an early and ardent supporter of the fomenting of INCOSE. He has led self-evaluation of Systems Engineering education, and continues to be one of the most prominent theoreticians of the Systems Engineering community. In addition to his teaching, writing, and consulting, he has participated in pro bono projects to bring a Systems Engineering approach to social service organisations.

INCOSE (2003) “INCOSE’s Pioneer Award” text; cited in: Wayne Wymore biography at incose.org, last updated: 19 Nov 2007.’

Wow, that’s impressive. So Dr. Wymore actually founded the whole Systems Engineering way of thinking. How come the definitions are so different?

The answer can be found, interestingly, in the auto-biography of Dr. Wymore, written by himself (http://sysengr.engr.arizona.edu/wymore/WWAutobiography.htm):

“Now (1987) I had a chance to finish the book on which I had been working for 11 years, since the publication of Systems Engineering Methodology for Interdisciplinary Teams in 1976. This was to be the book that I write for myself, for pleasure, with little regard for the existence of a market. It would be mathematically as rigorous as I was able to make it and it was intended to include every aspect of system science that would be necessary for successful systems engineering.  The rigor doubtless would be tedious for the present day systems engineer.  It might take a generation or two, perhaps more, before the profession would see fit to train systems engineers at a sufficiently high level of mathematical sophistication to qualify themselves to take on the design of a really vast and complex system such as the national health care system.”

Please, note the *the rigor doubtless would be tedious for the present day systems engineer*.

Has those two generations passed already? Or perhaps just one? 1987-2017 = 30 yeas.

So, basically, Wymore had seen the power of mathematics in describing all possibly thinkable systems, back then, in 1967. But even today, in 2019, we still don’t have sufficient enough computing systems to implement all the prerequisites for a self-supporting, computable Systems Engineering ecosystem.

Well, I have said ‘Systems Engineering’ so many times, and still hasn’t properly explained what it is.

The problem, it IS a bit hard to explain what it is. The informal definition of ‘assembling systems from pieces’ leaves more questions than answers anything.

Actually, Dr. Wymore actually had the same feeling, so he decided to give the same subject a more fundamental, mathematical base.

So, from a mathematical point of view, systems engineering is sort of a mathematics, and a skill of solving equations in a special functional space, which Wymore calls an ‘admissible input functions’ space. Without getting into too much detail, it is a somehow queer space of functions, which can have quite a lot of discontinuities, and are not obliged to be in any sense smooth, but are required to be sort of scale and shift independent, representing time and space isotropy.

Wymore claims that almost all imaginable systems (hardware or software, or even human organisations) can be represented as formulae on top of the ‘admissible functions’. And he builds a relatively comprehensive theory, describing how to relate various mathematical descriptions of systems requirements (input, output, state) with his definition of what is a system.

Interestingly, the most ‘meaty’ thing, that is how to actually describe a system mathematically, is given very little attention in the book. Because that is, supposedly, heavily dependent on the nature of the system built. But if the system IS already described, Wymore’s theory is ready to give some insight on how to predict the system’s behaviour, and how to use the power of mathematics to partition the system into parts. (Which IS, in some sense, the main thing expected from a systems engineer in practice.)

Remember, this book comes from 1967. There is, however, the second book in the series, written in 1993 (*model-based* systems engineering), which puts more emphasis exactly on those two missing aspects of the theory. On modelling and on simulating. (I haven’t yet read it, but it’s on my plans.)

You would ask me: how does it actually work in practice? Is Wymore’s mathematics actually used somewhere?

The answer is a bit disappointing. I haven’t seen any applications of the theory, and more modern books on systems engineering seem to be full of marketing bullshit, not of consistent mathematics.

Why? Well, so far, the world is still ruled by people more focused on intuitive thinking, rather than mathematical thinking. And I don’t see much of it changing in the foreseeable future. And Wymore’s theory seems to be in the worst possible location for a mathematical theory. It requires the users to be BOTH mathematics-savvy, AND having good intuition in those places where no good mathematical theory exists.

But how is Systems Engineering working nowadays then? Well ,the actual answer is ‘difficultly’. In the situation when you can’t force people to not just know mathematics, but even learn programming, you’re left with an only option of ‘programming people’ by writing documents. And to some extent, the systems engineering of now, is a science of writing instructions for people, and drawing diagrams (rather than writing code), because generally, unprepared people are easier at understanding graphics, not text.

I guess, you’re starting to feel where I’m going to. I am going to SysML.

SysML (and UML) is an attempt to make programming ‘imprecise’. That is, actually, a software program is always a model of behaviour of some system. But too often we cannot formulate the system precisely enough to actually write a robot to satisfy the system specification.

Nevertheless, we often can at least sketch the system’s definition in UML/SysML. (And frankly, it was a very bad idea to make the canonical representation of the language graphical, not text-based, but thanks to PlantUML, the situation is now much-much less cumbersome for people like me, who like precision.) Who knows, maybe at some point we will actually have better tools for the interaction between graphics and logic (code). Maybe the second tome (1993) will give me more insight into how this works. Especially since Wymore seems to be providing a more computer-friendly language called T3SD, a domain-specific textual language for describing systems. Maybe it will serve as a good bridge between the mathematical and the visual parts of systems design.

So, getting back to the Mathematical Theory of Systems Engineering: The Elements.

This book is definitely a must-read for a systems engineer. If you don’t understand the mathematics behind what you are doing, you’re not doing it right in any respect.

Is it well written? Well, in almost every aspect — yes. I feel some influence of the social nature of the systems engineering job — the book has a rich vocabulary, and with an exception of several rather confounding theorems, is clearly and consistently written.

Is this book of immediate practical applicability? I wouldn’t be so sure about this, but maybe the second book will change my mind.

Is this book enough as a first introduction into the subject? Still, no. Systems engineering in practice is much more than just mathematics behind the system specifications. Some practical information on how to do *informal* descriptions of systems is seriusly needed.

And, I guess, for every subject I’m reading about, I should be asking myself a little bit weird question: “should such thing be taught in middle school?”.
And in some sense, I would rather answer “yes” than “no” to such a question.
I still remember studying physics at school, and I do remember than one of the biggest complaints I had about it was that physics was presented to us as just a set of disconnected, scattered facts, each of them having a different structure.
Having then not interconnected was already bad enough, but it was the inconsistency of internal structures than was really driving me crazy. (I still don’t know physics, even though I am working (!) as physicist now.)

And in some sense, the MTOSE book is making a small step towards providing a unified base under various physical models and phenomena, and also can be seen as providing links to the other modellable subjects, such as biological phenomena, for example.

Should you read the book? I don’t know. I guess, we need a simpler book on systems engineering for ordinary people, which would still keep at least a trace of mathematical rigour. But this one… perhaps not, unless you are a working engineer or a mathematician. Then — yes. And of course, if you are a systems engineer, it is must.