[Tue Feb 19 21:25:16 CST 2019]

The Register explains that the original CERN browser designed by none other than Tim Berners-Lee has been rebuilt in preparation for the 30th anniversary of the proposal that gave birth to the World Wide Web and, to tell you the truth, although the browser looks very primitive, I feel sort of nostalgic. As a matter of fact, I wouldn't mind to use a browser that shows pages like that (i.e., in plain text) most of the time, especially if it has vim bindings. Yes, I know, it looks aged, primitive and boring. Still, most of my work involves reading, understanding and parsing text. Most of the time, I don't need anything flashy. Pictures and videos just get on my way. Sure, there are also times when I want to see pictures or videos but, like I said, for the most part, my work involves dealing with text. Yet, your average browser these days is way overkill for that (as well as distracting as hell!). Yes, I know there are alternatives. But, for the most part, they don't work very well. And yes, I know, usually, it's not their fault. It's just that the Web these days is full of junk. Oh, well. {link to this entry}

[Tue Feb 19 21:12:18 CST 2019]

I've always seen the Debian mailing lists as an excellent source of information to learn anything Linux. Recently, I came across a discussion on why Firefox was not redirecting to a wifi login page that drew my attention, since I just happen to be in a hotel right now and see this behavior every now and then. In theory, once I connect to the wifi network, it should bring up my browser window with a login page where I can enter the password, and away I go. However, the truth is that it only does this a few times. For the most part, it just fails to bring up the browser at all. Mind you, this is not a Linux issue. I also see it on the iPad Mini and the Android phone. In any case, the solution proposed in that email message (i.e., bringing up the NeverSSL page on your browser immediately after connecting to the wifi network) appears to work. The reason is that we have to use an address that is not truly an HTTPS URL, since that wouldn't allow the connection to be hijacked and redirected to the login page.

Then, from this other discussion (in Spanish), I learned a bit more about socket connections. Although I already knew about things like the fuser command to find out which process is using a particular socket so we can then kill it, it is a good thing to know that the port will remain in use for a while even after the process ends. It makes perfect sense. After all, there could already be packets on the wire addressed to the process behind that port, so it doesn't sound reasonable to immediately remove one process and allow another to take over the port.

Finally, from this other discussion, I learned that systemd allows to dynamically allocate a UNIX user ID to a process on the fly. Not something I'm going to be needing anytime soon, I think, but it's good to know the feature is there. {link to this entry}