Without a case I might recently have had to either replace the screen or possibly get a new phone. Screen several times because for some reason I keep dropping my phone recently (have had years without incident and suddenly there were 3 in a very short time). Actually when I fell with my bike (my fault, nothing happend except for a few scrapes and dented bike baskets), the phone jumped out of the case onto the street but apparently at such a low height that nothing happened to the phone though the case has a few extra scratches.
The other time I dropped it on the tile floor at home.
Third one it fell out of my (not deep enough because womenâs clothing sucks too often still) pocket onto the sidewalk.
Question: is there any âgoodâ solution for a browser on my ipad? As far as I know everything is Safari. And Firefox iOS experience has been degrading more and more But even if it is just a front-end it shouldnât be so awfully slow, crashing all the time and forgetting tabs.
Vivaldi for iOS is on the way. Itâs in limited release for public testing at the moment, with more slots announced through their mailing list. Iâve been using it and itâs pretty good so far.
In news of technology actually making my life easier, I have been using ChatGPT to help me prototype bash scripts. In related news, my bash skills are improving rapidly from figuring out whatâs wrong with the prototypes.
Iâm also considering whether I should be retraining as a plumber for when the machines make me redundant.
Personal opinion: once a bash script is more than a few trivial lines, and certainly once it grows logic, itâs time to move it to your language of choice â now, while thatâs still a relatively easy task. Because using bash means you eternally have to be on the lookout for shell escaping and expansion problems which simply wonât be a thing anywhere else.
I will concede that if youâre better at bash than I am this may be less of a problem for you than it is for me, but Iâve never regretted moving something from bash to Perl or Python or Ruby orâŚ
Iâm generally of that opinion, but there are times it makes sense to use a shell, usually when you can canât be sure the alternative you want to use will be available. I had to write some awful bash because it existed, and a usable python did not, on a system I deal with.
I wrote a web application in awk once, what these days would be called a micro-service, but it was the 20th century, and those hadnât been invented yet. Content management was done with make, of course, which was triggered by procmail.
I wish i were making that up. (More usefully, I also built a front end to hpuxâs logical volume manager in awk. read a table, the state of disks, physcial volumes and logical vols, and made changes to state to match the table. )
*glances sideways at a 4,268 line bourne shell script I wrote and maintain*
(That was âon purposeâ, admittedly⌠I wanted it to be a run-anywhere POSIX-compatible thing.)
My longest bash script is only ~2,500 lines! :â)
(Although a bunch of that is embedded TCL code for expect â and wrapping up that in a shell script was a whole lot nicer than trying to write the whole program in TCL, which is what I started out attemptingâŚ)
I guess my predilection for shell scripting might be akin to Stockholm Syndrome, but itâs always been my go-to.
I used to write small (10-20 lines) shell scripts for various purposes I was otherwise unable to automate.
On my current server, the only one I have is one that copies a bunch of files between 2 directories, when I click a button in a webapp that used to be php and I wanted a clear disconnect between the app and the file-copying because no php script I wrote should have access to any directory that is associated with my mailserver. The script is triggered by inron. The app is now in python.
Then I discovered the joy of ansible and shell scripts no more. I struggle and my ansible scripts are probably not pretty or professional but the amount of automation I need is not that much. So I get away with my small bit of knowledge.
I am a fan of awk. It is very useful in quickly analyzing files. I also once based a huge perl-script I wrote on some awk commands that analyzed webserver states for a huge bunch of webservers and stored everything in RRD files (I donât know the exact library anymore they were very popular then for tracking server stats). That was in 2003. I think the great-great-grandchildren of the perl script are probably still running somewhere at the companyâthere was later a whole team running itâbut I am 100% sure no more perl or awk involved.
Many years ago I decided I should improve my sed and awk knowledge and so I read a book on those, and by the end⌠I knew why perl had been created :â)
But even if it is just a front-end it shouldnât be so awfully slow, crashing all the time and forgetting tabs.
