Re: Sorry...
Oh, yes there is. Install an ad-blocker.
42420 publicly visible posts • joined 16 Jun 2014
"you probably have a better chance of getting the advertising right, if you look at the page I'm reading"
Do you want to take the bread from the mouths of the advertising industry's children? The publishers could do that and cut the entire advertising industry out the supply chain.
The ad-slingers know this perfectly well and they don't care. Read that again.
They don't care. They have no interest in selling you anything.
They are actually very good at selling but they're not even trying to sell anything to you.
They sell advertising to advertisers.
You might wonder why they succeed when that uncomfortable truth is so obvious. It's easy. In a big business they have allies in marketing departments. Some of those may well realise that but also realise that their entire careers depend on pushing business to the advertising industry. And in any case even if the advertisers realise that all the adverts they see are obnoxious spam they themselves are very special and their adverts aren't spam, they're valuable marketing messages.
I've often made the point here that the advertising industry only sells advertising. "Do you want to show an advert to someone who's interested in buying buying a dishwasher? We know who's interested in buying dishwashers. [soto voce We know because most of them have just bought one.] Just give us your copy and lots of money and we'll make sure they see your copy every time they go online."
It's hard to believe that the customers, the advertisers, aren't kept in the dark as to just what they're getting for their money. The operators of this sort of scam don't need to confine it to the web. They can offer a spam as a service in the same way.
At the lower end of the market the delivery is to every address that's been scraped of Usenet or anywhere else more than a decade ago*. A lot of these offer some sort of business service such as SEO, website development or more recently mobile app development. The alleged senders have obviously been sold leads generation as a business opportunity, not realising they themselves were the actual business opportunity for whoever sold them the service.
To get into that sort of business you don't even need a great command of your email software. For instance I've had a string of spams all with "Re: " in front of the subject so it looks like one email being sent to a script that responds as a reply to a BCC list. However the first version had a bug: all the emails had the greeting "Hello wilfosula gmail,". Today, however, I find the script's been improved. It now has my name in there. However it's exactly the same text as the last of the wilfosula emails and what's more two arrived together but with different reply addresses.
They usually get a variation of my potential supplier questionnaire. That starts off by asking business-like questions they won't be able to answer such as their registered business name, domain name and, for SEO, their web address so that I can test their ability by finding them on the first page in Google when I Google for "First page in Google". It works round gradually to asking them if they think they can get their money back from whoever sold them this shit. Given the nature of today's pair I CCed the questionnaire to both of them.
* These emails all arrived at an address that I haven't used on Usenet for well over a decade but it's one I still use for some purposes. If a more recent Usenet address were to be used I'd set it to bounce with a "because of spam" message for a while & then just kill it.
Add possibility of completing task.
I've often thought that testing should be carried out by a group of 3. One is a developer; one is a tester, a user familiar enough with the domain the application deals with but not with the application itself; and an invigilator. The tester is only allowed to ask - and the developer to answer - questions of the form "Where does it tell me how to do X?". Nominally the invigilator's role is to enforce this rule; it's actually to stop the other two coming to blows. The actual purpose of the procedure isn't to test anything, it's to teach the developer how to design a user interface.
I can only think of one use case: let's run LO in the browser because we can. For any use case involving editing a file on a remote server there are better solutions,
If only port 80 is open on the firewall Own/NextCloud will let you edit locally and manually upload through the browser. You can cut out the browser by using the O/NC desktop client to sync selected local directories with the remote. If you don't want to have the file local at all both LibreOffice and, AFAIK, MS Office have Open Remote available through WebDav. It's a while since I tried this on LO and memory says it was a bit of a faff; that might be because I didn't use it enough but no doubt it would be easier to make it a bit slicker than to get this idea working.
If SSH is also available use X over SSH to run an X-server locally and LO on the remote. An X server was the first use case I had for Windows? Is it still possible to get one?
I think an office suite would be the wrong tool. What happens if two people try to edit the same passage at the same time? You'd need to have locks on selections or on the current location of everyone's cursor (think one one person doing character by character deletions while someone else is trying to type there). It would end up more like a transactional database at the back end with an HTML generating front end....
Hold on there. That's a Wiki. That's what you need. Then you can typeset the result.
" Paramount is the multi-user part, where documents are accessed simultaneously by the users. No need to do too fancy formatting. Final formatting is a one-man job anyway and can be done in a local LO copy."
I wonder how the practicalities of that work out. If two people want to express the same thing differently somebody's going to have to arbitrate.
Maybe an alternative approach would be to save the working text in a flatter format - maybe .fodt or .md - managed with Git so the final (human) editor does the merging and formatting.
"all work-arounds for problems you wouldn't have if you just compiled statically"
If any of the libraries you compile in has a vulnerability that won't be fixed by the user updating the shared version.
A better starting point would be to set the minimum dependencies as the oldest versions of every library that provides all the facilities you use.