Compared to Lars, Jon was hands on, and connected with the staff and products. I think I can count on one hand the times I saw Lars eating in the canteen. The company changed a lot after that, and not necessarily for the better.
What made Opera great was the people working there. The amount of knowledge and raw talent that lived in the tight hallways of Waldemar Thranes gate 98 was impressive. Looking at Vivaldi's "Our Team" page, it looks they have almost recreated the same team from back when I joined. I miss that period!
I had the pleasure of working with the people from Fastmail while they where owned by Opera Software. I had a lot of respect for how they operated their systems back then, and I'm sure it's even better today.
I miss all the Tim Tam's they brought to our Oslo office!
During the first larger round of layoffs that happened in the "original" Opera Software, the Head of HR stood in front of the employees and managed to say something like "We are not 'downsizing', we are just 'right-sizing'".
Personally, I think it is because search is a important revenue stream for the browsers. It makes little sense to put too much effort in to a feature that will limit the usage of the thing that earns them the most.
At Opera Software, where I worked for a decade, both speeddials and bookmarks was important streams of income, but it was nothing compared to the income from searches.
As a person "self-diagnosed" with aphantasia, I feel cheated knowing that other people have a built in cheat-sheet. No wonder why I was struggling with memorizing things like the multiplication table in school.
That page was often used at Opera Software as a example and benchmark for weird and wonderful things "web designers" throw against rendering engines :D
The Opera product you are thinking of is Opera Mini. Opera Mobile is a browser running mostly on your device (except for "turbo" which optimized media trough a proxy setup, but did not, afaik, execute any of the javascript).
Opera Mini can be looked at as a browser running in the cloud, sending OBML (Opera Binary Markup Language, if I remember correctly) causing the (very thin) client to draw things on the mobile screen, like text, images, etc without having to transfer, parse, execute, flow and paint every thing on the device.
The truth is that most services will have a set of devops with access to personal information. And some times, we need to look at private data to solve issues like this. My first instinct back then was that some smart hacker had created a FUSE support for Link or something similar.
Opera Link did not encrypt bookmarks and speeddials etc, but had datatypes encrypted with master password, even while syncing. We where two people with the access and knowledge to access individual user information, and we took it very serious.
I worked on Opera Link, the first built-in synchronization between different installations of the Opera browser, both desktop, Opera Mini and Opera Mobile (+ a web view).
Favicons got included in the data from day one, and it was awesome to get the look and feel of your bookmark bar/UI with the correct icons right away.
Back then we stored the booksmarks in a home grown XML data store (built on top of mysql, acting more or less as a key-value store). This worked quite nice, and it allowed us to easily scale the system.
One night the databases and backends handling the client requests suddenly started eating a lot more memory, and the database started using much more storage than normal.
As one of only two backend devops working on Opera Link, I had to debug this, and find out what was going on. After a while I isolated the problem to a handful of users. But how could a few users affect the system so much?
As a part of the XML data store, we decided naively to store the favicons in the XML, as a base64 encoded string. While not pretty, a 16x16 PNG is not that much data, and even with thousand of bookmarks, the total overhead on compression and parsing was neglishable. What we did not foresee was what I uncovered that night; A semi-popular porn site had changed something on their server. They had started serving the images while also pointing browser to the same images as the favicon! Each image being multiple megabytes, sent from the client, parsed on the backend, decoded, verified, encoded back to base64, added to the XML DOM, serialized, compressed and pushed back to the database...
Before going to bed that night, I had implemented a backlist of domains we would not accept favicons for, cleaned up the "affected" user data, and washed my eyes with soap.
The "hidden" gem here is all the videos posted by Andreas on his youtube channel. I've spent quite a few hours with him and learned a lot of things from his way of working.
I'm not a chemist nor physicist nor biologist, but..
What do you mean with "inert"? I'm pretty sure most radioactive elements are quite happy to react with other chemicals, like salt water.
Some of the new compounds will be water or fat solvable, and can find it's way in to our food chain. The gasses and particles from the nuclear tests around the world was also fairly localized, and if something was spread, it was diluted in a vast vast amount of air. Still, there was long lasting effects on humans and animals, some of which we are still discovering.
Trolling, the fishing method. For me, a internet troll is a person that says something provocation hoping that someone will "bite" and waste time arguing.
I guess it depends on how strictly you define a ballistic missile. I would think most warheads have some sort of terminal guidance. The only difference is that Falcon use the engines mainly to shed speed so that it does not burn up during entry, and dont destroy the barge on "impact".
But, yeah, when they do boost-back to the Cape, the analogy breaks down even more.
10 users with simple needs = complex software.