Why is REDHAT so Awful?

I am not a Debian weenie.  I have been using REDHAT more or less constantly for over a decade.  True, I have been using the Centos variety of REDHAT but nevertheless.  But why oh why does the Redhat site need to be such a bureaucratic mess?  Why so difficult to use?  Why is everything such a pain in the ass.  And good luck getting support.  ChatGPT would be a blessing over what they have now.

Illustrations courtesy of Midjourney.

Why Group Sourcing is Obviously Stupid

draft

At various times people talk about "group sourcing" on the internet, or of learning from the internet from the sources that people provide for free or even for a fee, as if it will just be there.

This is not only wrong, it is stupid, it is even obviously stupid, as anyone would know if they had actually tried it to learn something seriously that way.

The reason is that the noise to signal is wildly out of balance.  And there is no way to judge noise from signal in the general case without a vast amount of time and effort.

Group sourcing is obviously not as good as a credible source with information that has been vetted.

Duh.

I guess the people writing about the Internet dont know what they are talking about or maybe they are just lying to steal the money.

The Yelp User Experience Sucks

draft

So I want to give a review of my local water company, Rincon del Diablo Metropolitan Water District, which also sucks, so I want to use Yelp. So I write my review and then of course have to create an account on Yelp or use my Facebook account. Aint no way Jose I am going to give fucking Yelp my Facebook account so I attempt to create an account.

And I descend into hell. Yelp hell. As if the people who run Yelp dont have a clue how to write their way out of a pay toilet, software wise.

So having reset my password a few times and log in I get my little post posted! Hallelujah.

Now does anyone know how to leave a bad review for Yelp on Yelp?

The Insanity of Software in 2016

draft

Whether or not I was having a fabulous career today, I would still have to work hard, like everyone else, to keep up to date and learn new skills.

Since it is a part of my self-image to be very knowledgable about the nuts and bolts of doing things with computers, then that certainly means being up to date on how we implement things on the Internet, and that means learning how to write Javascript for various browsers (and in some language, possibly Javascript, for the server side).

Some of this technology is good, some of it is lousy, some of it is very good, it is all over the map. But the real problem is that it is total chaos, total insanity, and there is no rhyme or reason.

I am going to let someone else make this argument for me, and you are directed to a wonderful little article called How it Feels to Learn Javascript in 2016.

Yet Again, the Problem is the Documentation

There are several unwritten rules about the Internet and we might as well make them clear up front. The first is that everything is great, and if you dont say and acknowledge that its great then you are an asshole and must be ignored and written off as someone who complains.  And I do complain so they are correct.  The second rule is that the documentation sortof sucks, and it does.  It is not intentional on anyone's part that the documentation sucks, or rather is uneven.  It is just the way things turned out.

Now for some details and a specific example and one more time it is not the technology per se that is bad, although of course there are always things one might like to change.  The problem, as always it seems, is that the documentation is either wrong, inadequate or overwhelmed by noise that masquerades as signal.  And that noise manifests itself as "helpful" documentation available on the Internet and authored  by the "group mind" that is, unfortunately, wrong or out of date or replicates what is already there or all of the above and there is no easy way to tell the difference.  As a result, the anarchic state of the documentation makes learning new and possibly better approaches on the Internet annoying and much more time consuming than it needs to be.

Websockets is the “new” approach to client server communication for browser applications. It does not look like much, but it is apparently almost as good as what we had with the Arpanet on day one in 1972.   As I read more about Websockets, I realize that there is a lot of thought that has gone into it in fact just because the Internet is not the ARPAnet and there are a variety of considerations that this forces on the design of technology like Websockets.  

Now Websockets is marked as experimental and is also considered to be incompatible between various implementations/browsers. However, it seems that is old news and that there are good implementations in most browsers and a variety of frameworks to hide differences between browsers.   For my application, I am not too concerned about this as my specific application is more of a proof of concept and we can finesse such things as working transparently on all browsers, for example.

But as always, the documentation is ad hoc.  There are many different frameworks one might use for your server side implementation.  Each of them has a different approach to documentation. Just choosing between the different frameworks (in this case that works with node.js) is itself a chore and a half.

For example, the websockets.org site has the source to an echo client that runs in a browser and is written in Javascript, and they also run a live echo server on their site.   But the source for their echo server is not available.  Why not?  And there is no contact information on their website such that you could ask them that question or any questions at all.

I presume that the people involved in all these technologies and frameworks are not lazy nor stupid.  I suspect that there is a combination of things going on here.  They include such things as (a) being not particularly talented at writing documentation nor enjoying the process, (b) not realizing that such documentation is necessary, (c) balancing the needs of this project with other responsibilities, (d) relying on someone else to do it, and (e) actually believing the groupsource myth that says that other people will write it for you.

My guess, my personal guess, without enough information, is that Websockets is an effort by an elite who simply do not understand or care that people learning their protocol who have not lived with it as they have on their committees will need more documentation and usable examples to make good use of their time.  It works for them.

If you dont like it, well its the Internet, and you dont have a choice.

[Addendum.  As time goes by, I penetrate more of the mysteries and it is not too bad. In fact, it may even be reasonable.  But Jesus, they really don't try to make it easy for you.]

Corruption and Degradation in WebGL (revised)

This review was written about a week ago when I was first into my learning curve of javascript, html, dom and webGL.  Well, its a week later and I think that what I was really responding to is / was different than what I thought it was.   Its not about WebGL, its about expectations.   See note at the end of the post.

This is a review on the process of learning Javascript and WebGL. The two are very interconnected and we will start with Javascript and then move to WebGL.

Note, I am not far enough along to have a real opinion about how well WebGL works, because I am spending all my time getting through the learning curve of getting a picture up on the screen. It shows promise, when things work it almost seems magical.

But when you first are learning WebGL you have to get through Javascript so we will start there.

Although Javascript is a little weird, it does grow on you, and there are clever even possibly reasonable solutions to various flaws in the language which, once you get used to their weird syntax, seem to be OK. For example, I am using a variation on the "module" pattern in Javascript and it seems to be working out for me in terms of hiding and keeping internal state of various parts of the program. Furthermore, javascript reminds me a bit of Lisp in its devil-may-care attitude to dynamic memory and its JSON equivalent of an S-Expression. Although initially dealing with Javascript is a problem, in time the problems fade into the background.

The problem is that learning Javascript is something of a pain in the ass, and for the following reasons:

1. Javascript has a specification and a bunch of tutorials, but no serious reference manual or best practices documentation. You are expected to get all that "out on the Internet". Ha.

2. The problem is that each of these tutorials is written by a different person with wildly different skill sets, styles and talent. They are not Kernighan and Ritchie. They are not comprehensive. They are occasionally helpful, they are more often then not incomplete or inaccurate. They are in no way a substitute for a good reference manual.

3. Each of these tutorials by helpful unpaid volunteers uses a different style, and a different set of support packages, all of which are completely incompatible with each other. There is no equivalent to "stdio" in Javascript. One person uses Ajax, another uses Jquery, still another uses something else. These different packages all seem to be useful, ad hoc, mutually incompatible and of wildly varying quality and utility.

4. Learning Javascript is usually intertwined with learning some combination of DOM and HTML, each of which exists in its own versions, varying implementations, and without documentation. Repeat problems of learning Javascript for each of these.

5. Unless you have someone with the knowledge and the time to guide you through this morass, you can count on a very frustrating period and a very time-inefficient process. Its nothing that anyone involved should be proud of. Just because they made a billion dollars at it, does not mean that they did a good job.

But the good news is that, so far at least, in conjunction with a nearly Lisp-like level of interactivity, one can pretty quickly get through the learning curve and onto whatever it is you wanted to do with the language.

But then you get to WebGL and you run into a series of problems which are very related to the ones just mentioned but with a few additional ones to make it all better. Not only is there no reference manual, nor anything close to minimally acceptable reference documentation (a specification is not a reference manual, by the way), but one more time we have the morass of internet tutorials that vary from useful to not, and each of them uses their own support packages for matrix operations and so forth.

But unlike Javascript, with WebGL and all modern graphics APIs, you have to do an awful lot correctly before you can put a cube on the screen. And if you do one of those 30 or 40 things incorrectly, then you will not see a cube on the screen. But each of those 30 or 40 things is badly documented since there is no reference manual, so you are reliant on Internet based tutorials which brings us full-circle on the discussion.

The only way I have found to proceed is to divide and conquer. Which is to work your way through the creation of a working program one module and WebGL call at a time, reverse engineer what the documentation should have been, and then move on.

That takes time.

I am not all that impressed, to tell you the truth.

So now it is a week or so since I wrote the above post.  And I think I was being a little harsh.  Once you get through the learning curve, and get a handle on what documentation that there is, one can become productive.  There are still unsolved riddles but I am able to move around them.   I think that the real problem here, however badly expressed, is one of incorrect expectations.  I expected things to be better, for us to go forward with the best, and not to have to deal with things that are no better designed or documented than what we had 20 years ago.   It is perhaps a let down that we have not come very far in certain ways and that is what I think I was expressing above, without knowing it.  As for the rest, Html, Dom, and even WebGL is fine, if a little weird now and then.