The end of flash

Adobe was not the originator of flash, nor was it the only technology created to bring various multimedia effects to web pages.  Today is the last day for Adobe Flash, and so a number of FreeBSD ports will find themselves made defunct, already long deprecated but soon deleted.  It has been a sort of zombie tech which was supposed to have been dead and buried long ago, but has continued to remain.  We can now finally be satisfied that a stake will be driven into its heart, its bones salted and burned, and never will it haunt us.

• https://www.freshports.org/www/flashplayer/
  


• https://www.freshports.org/www/linux-flashplayer/
  


• https://www.freshports.org/www/get_flash_videos/
  

This will not be the only group of things which vanish in the coming weeks, as the addons for web browsers which were designed to control flash or remove flash will now also no longer be needed.  I strongly suspect however, that one remnant of flash will persist, a special sort of cookie which was intended to be persistent and resistant to removal.  One of the most odd uses of flash may be aspects of security controls, such as a type of second factor authentication, or password entry on some sites.  I say that it is odd due to the fact that flash was one of the technologies used on the web and web browsers which has to have been among the most frequently patched for security exploits.

• https://addons.mozilla.org/en-US/firefox/addon/clear-flash-cookies/
• https://addons.mozilla.org/en-US/firefox/search/?q=flash

I do not mourn the passing of flash, I rejoice!  Does anyone remember Beatnik, an amazing technology which brought music and some other effects to the web?  How about the truly artistic and interesting web pages from authors such as Doc Ozone?  The web these days has become a bit sterile and tired.  We can only hope that the successors of flash will attempt to be as grand but without all of the troubles, mischief, security lapses.  I also hope that any trend on the web be toward standards that are universal, that do not require one operating system over any other, or ever become proprietary which would mean the exclusion of many not-so-mainstream users such as of FreeBSD.

So long and thanks for all the fetchs

No sooner than my blog post about the retirement of svn in lieu of git becomes popular, do I hear of another transition.  I guess I should count myself lucky that poudriere is not planned to be obsolete in a month.  It is even more obvious that I am quite out of the loop with regard to these sorts of changes but as both are rather significant one would believe that there would be a bit more noise about them.  I frequently read the quarterly FreeBSD reports but do not recall either transition being mentioned.  Did you know that portsnap was set to be retired?  There was a mailing list mention in August, and a FreeBSD forum mention once upon a time.

Portsnap always felt speedy and efficient.  It has served me well.  Now I will have to move poudriere back to svn, revise my little ports tree update script back to svn, and look into git or svnup or other tools to see which works best for me.  Thanks to Jailer and his post for helping me to discover that I have to retire portsnap.  I need to find the appropriate retirement schedule for it.  The other issue I have run into on my system is the difference between what I was receiving from portsnap in comparison to svn.  I might guess now that portsnap was older but that depends upon various settings for which branch/version of the ports tree each tool downloaded.  I will also eventually be revising some other blog posts to indicate my chosen alternative to portsnap.  For now, the forum post below may give some ideas on what I might try.

What I have discovered since then is that there is a reasonably simplified tool which can handle both ports tree updates whether quarterly or not, as well as the source for kernel and world updates.  As I mention in another blog post, net/gitup was most certainly a tool without fanfare and it is what I have chosen for keeping my ports tree up-to-date outside of my poudriere jail.

VCS changes again

Maybe some of you do better at keeping track of scheduled events, or you're a bit more in touch with the process.  Just a few moments ago I saw a tweet warning "heads up!"

Within the last few days I had noticed that it was 20-something days since my last reboot or update, so I did an svn update of /usr/src and rebuilt, reinstalled.  How serendipitous that was.  According the the wiki page mentioned in the tweet, this might not be possible later this month.  The image below might quickly become invalid but that was what I saw, note the 19th.

 

For some time FreeBSD has had svnlite in base which could be used to obtain an updated /usr/src or /usr/ports but with the switch to git I wonder if there will be git-lite or similar.  I would have to believe that poudriere would no longer be able to use svn+https to get /usr/src or /usr/ports.  So although the capability would not be removed since anyone could still use svn themselves for their private repo, it won't be for official FreeBSD.  Since I still have until December 18th for certain, I will make sure to do one last update to my /usr/src.  The small bit of trivia would be that once upon a time FreeBSD switched from CVS to SVN (2008) and they decided then that Git wasn't capable.  I cannot say whether Git changed or something else did but its surely good enough now, but for how long?  What will be the successor to Git and will it be BSD or MIT or similarly licensed?  If removing GPL from base would prevent git from being part of it, is there a non-GPL client much like svnlite which could be included?

They keep this around for entertainment:  https://wiki.freebsd.org/VCSWhy

I will have to investigate whether there is a way to do much of the same things as I had with svn, because after so many years I finally had everything figured out and the details put in one easy to access place.  I cannot imagine that all of the methods below have no equivalent. 

Proxy tuning fun

I really like the idea of a proxy cache for use with the various websites I access regularly, it seems to speed up load times considerably.  My OPNsense firewall/router offers Squid for the caching proxy capability.  I have played with it in the past and as much as I knew then it was doing what it should, but I was never certain of that.  Back then, when others besides myself were using the network I set up, I had enabled Squid to hopefully improve things for their frequent web access.  When they decided to find connectivity in other ways and left the network, I eventually removed the proxy cache.  After some time I enabled it again for myself and discovered it was one of only two things that might prevent success of the wonderful self-contained do-everything-itself firefox, the other being physical disconnection of the coax or Comcast connectivity failure itself.

This means of course that there have been a few times when the failure of the proxy has meant firefox also failed.  In the past, I simply turned on the proxy and set it for transparent.  More recently I setup the Proxy auto-config rules, and as before, as far as I knew everything worked and web site loading was improved.  As with any other new 'toy' or function, you go back to it to play some more, to tweak it and see if you can make it the most efficient.  I am not sure why, but if I set the SSL cache size too high, the proxy fails.  Luckily I knew that this was what I had adjusted most recently, so all I needed to do was attempt to return much of the configuration back to what I had when it was working.  Along with this was fighting with firefox as well to make it understand that it should not try to use a proxy.  Eventually I bumped into the issue with the SSL cache size being too large though why it causes any failure I do not know.

The largest I have discovered that still works is 768 (in mb) with the number of SSL workers set at 32 of a maximum of 32.  What I don't quite understand is that even with all of the proxy auto config settings described later in this post, firefox fails when I turn off 'transparent http proxy' while firefox itself has 'Auto-detect proxy settings for this network'  set in its network config.  I blame firefox for this failure, especially since everything else seems improved by the end of this blog post.

Since it seemed that the forward proxy configuration was now set about as optimally as possible, I looked over the other configurations.  I looked at the proxy auto-config rules and proxies and matches.  Since I noticed significant improvement, snappiness, after some adjustments, I am certain that what I thought was a proxy cache may have only been some re-routing of packets.  Below, the adjustment to the proxies is what seemed to instantly cause improvement.

With regard to the 'not internal to proxy' rule, what was missed was all types of proxies.  I am not sure which one of the three was entered previously but I suspect it was 'LAN proxy web' which seems reasonable, until thinking about what the rule is about.  The rule essentially indicates everything but the proxy itself, so all proxies should be listed.  Below are the definitions of each of the proxies.  I have the svn url excluded with a proxy definition because I wanted to be sure it was not obstructed, though I may change this later, it is further excluded by a match.

Although all of these proxy definitions existed, tuning to more appropriate proxy types as shown above likely also improved efficiency.  I assume I had them set as simply 'proxy' but as soon as I adjusted them I forgot what they had been, as is normal but at least I settled on what is likely optimal.  The definitions of each match follow below.

The only other tweaks I have played with are the cache itself, and I admit not fully understanding how the numbers of first or second level subdirectories affects efficiency.

You might wonder about my OPNsense firewall box, how I can set such things which may seem rather large.  The motherboard has onboard graphics which is only necessary for console access and so does not cause much heat.  Addon cards for networking only.  The cpu and memory and hard disk and various other information below.