Posts by Doctor Syntax 40485 publicly visible posts • joined 16 Jun 2014
1. Throwing completely irrelevant junk into search results. Sometimes it might be a genuinely poor matching algorithm or the junk having irrelevant key-words but not always. Throwing in a bunch of key-words deliberately is included.
2. "You may also like...", "Other customers also bought..." and the like.
I had a client about Y2K time in printing. They too used an application that used Progress IIRC. Can't remember the vendor name. Another client, same industry, also had an industry-specific application that did use Informix on SCO. From the perspective of most sales and stock operations they do things a bit peculiarly there. The Informix based one had an interesting quirk. They were, I think, supposed to ship with a run-time only installation but they had ?accidentally left in one of the development applications - sformbuld IIRC. But as all the non-4GL development applications are all the same executable, just link to the relevant names and, ooh, look, a full Informix development suit.
"It's exactly why financial workers are required to take a two week continuous vacation every year."
Nothing suspicious about booking that holiday to somewhere that coincidentally doesn't have an extradition arrangement. Or somewhere where you can conveniently be declared dead and buried (or for preference cremated) before you're due back.
"I've also read a couple of papers suggesting the Earth has too much water"
I keep seeing this sort of thing reported.
It doesn't have too much water. It has the water it has. If the theory says it shouldn't have as much water the theory is wrong and the theorist needs a new theory, not the Earth less water. It's called science.
"For some reason Microsoft did not follow their winning strategy with phones."
I doubt the phone industry, manufacturers and networks alike would have allowed them. They saw the way the PC makers had been shafted and wouldn't have let that happen again.
James,
On the subject of PiTop, I got one years ago for my grandson. My reaction was that for that purpose the location of connectors didn't work out very well. In particular the power and headphone connector were on the same side and as the power connector needed to be internal there was no easy way to connect plain old phones or speakers. Perhaps it would be worth thinking about how best to lay out the connectors for this sort of purpose - and then about something along the lines of chromebook except running NextCloud as the server (on a Pi, of course).
"the company actively encourages staff to work from home!"
From home or at home? It's not necessarily the same thing. Someone covering, for whatever, reason, a geographical area remote from the company office may work from home but seldom be at home. Sales is the obvious example but not the only one. My daughter works in clinical trials and spends a good deal of time at the participating hospitals; the company office is only occasionally visited.
Perhaps you didn't understand it. If your concern is to get an item of data onto disk ASAP then you don't achieve that by leaving sitting round in the cache until such time as an algorithm you don't control decides to put it on disk. If you can do direct I/O then it's faster. OTOH caching is going to be best for overall throughput but does leave cached data at risk for some time.
If you're a good DBA you are paranoid about integrity and consistency of data. You assume there are things out there such as power failures ready to attack*. You don't like the idea that a page from this table might get written and a page from that not so that a join fails or returns incorrect results. You look for an RDBMS engine that can (a) do journalling so it can roll back incomplete transactions and roll forward those committed but not yet completely updated in the tables and indexes (b) coordinate its cache flushing with the journal, (c) coordinate all that with, if necessary, backing up the database whilst still continuing transactions and (d) have its parameters tuned to gain the optimum throughput. The parameters for that case are not necessarily going to be those suited for general purpose file system I/O, even a journalled file system; it's much more complicated case. In such cases the engine needs direct I/O so that the programmer can rely on data having been written when a write call returns.
Even with ordinary file system I/O Linus had a wake-up call back in the days of ext 3, or maybe even ext 2. IIRC memory sizes had gone up and as the file system simply made use of otherwise unused memory as cache and it transpired that instead of being flushed frequently because of lack of space, caches were sitting around until the kernel synced them on the basis of time since the last flush. Realising the possible consequences of this - possibly some data actually got lost - he commented "what moron put that in there?" or something similar.
I assumed that it was self-deprecating, the lesson having been learned. Ext 4, of course, being journalled, made things much more secure. But maybe not.
* Of course you don't expect this to be an everyday occurrence. Indeed, you hope you never have to deal with it, but then any system administrator taking routine backups hopes never to have to use them to deal with anything other than a careless file deletion by a user.
Linus has always had some sort of opposition to direct IO. One symptom seems to be the absence of character devices for disk partitions - something which has been part of Unix for as long as I can remember (V7 days). There are ways round it but it's a strange fixation. I'm not sure why he failed to grasp that applications such as database engines rely on their own journalling schemes for their integrity and that when a journal write completes the programmer should be able to assume that the data is actually in storage and not lounging about in cache and vulnerable to power or other failure.
"I have no idea why no government (anywhere in the world, as far as I know) has introduced an opt-in law for this crap."
Cough. GDPR. It's going to be a while before enough cases work through enforcement and appeals to make the offenders really sit up and take notice but it is opt-in.
"I have nothing to hide"
You could point out that they almost certainly have stuff which they're contractually obliged to hide. Pretty well any log-in credentials that access anything that deals with money and especially banking sites will, if they check the T&Cs, have to be kept confidential. How do they propose to do that if HMG have a back door into the communication? Avoid the online access altogether?
When I tell people about a product I say "it's available on Amazon". They google Amazon "whatever product" and click a link
Probably you know a lot of people who never found what the address bar is for. I'd start to type in amazon.co.uk* on the address bar, autocomplete would do the rest but that's only because I'd typed it in some time in the past.
Its value is as part of the branding and the branding has value because Amazon have put in the effort to build a search engine which works if you ignore the false positives, logistics which mostly deliver and humongous data centres and warehouses to support it all. Voice.com, OTOH?
* You're partially right in that the .com variation is less use that the corresponding name under our local TLD.
I had a similar experience with a cousin's new printer. In that case it was supposed to be set up via his W10 laptop. Between them, as I eventually worked out, they contrived - repeatably - to set it up on the wrong subnet. Much the same solution - USB cable and, in this case, his ancient Dell running Linux.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
