I found that far too readable... Obviously been at this game far too long!
497 posts • joined 12 Jan 2009
Footnote from Good Omens, by Terry Pratchett and Neil Gaiman:
"NOTE FOR YOUNG PEOPLE AND AMERICANS: One shilling = Five Pee. It helps to understand the antique finances of the Witchfinder Army if you know the original British monetary system:
Two farthings = One Ha'penny. Two ha'pennies = One Penny. Three pennies = A Thrupenny Bit. Two Thrupences = A Sixpence. Two Sixpences = One Shilling, or Bob. Two Bob = A Florin. One Florin and one Sixpence = Half a Crown. Four Half Crowns = Ten Bob Note. Two Ten Bob Notes = One Pound (or 240 pennies). One Pound and One Shilling = One Guinea.
The British resisted decimalized currency for a long time because they thought it was too complicated."
We had CDE running on Sparcstation 4s & 5s back in the day - I think they only had 16MB or 32MB of RAM. Some of the SS5s only had a 500MB hard drive (that was fun shoe-horning Solaris onto...), let alone memory.
One part might also be a move to 64-bit which has a tendency to inflate binary sizes, but that should only be a doubling at most and probably much less.
Had a much less hair raising experience with that - bought a 2nd hand guitar and got a chunk off because it was buzzing loudly when plugged into the amp. Took it to bits and discovered they'd wired the jack socket wrongly when it was replaced... 5 minute solder job to switch round the wires and no more buzzing :)
Now onto fixing the other issues like the frets needing polished, rusty screws replaced and updating the pots (one doesn't work, so might as well switch out the cheap ones for better models). I'm beginning to think I didn't so much buy the guitar as rescue it from neglect...
I still think this is the most accurate explanation of NFTs:
Back in the 90s, our uni lecturer was convinced that Ethernet was doomed and ATM was where it was all going. What changed was the move from coax, with all its myriad problems and relatively dumb hubs to fully switched networks. These helped reduce/remove the collisions which plagued early Ethernet networks and allowed it to scale up and out.
What is ironic is that Ethernet followed ALOHAnet which was a wireless protocol, making it wired. We've now taken Ethernet back to wireless with our wifi links. Everything turns full circle...
Aberdeen had Wintermute, I think I was with them before Demon. The Wayback machine shows my site on Demon from 97 to 2001 before I moved to ADSL, so I suspect I must been on Wintermute in 95 (when I left uni and lost the free access there) until moving to Demon in 97. IIRC, Wintermute folded or something, so that probably precipitated my move...
Laptops have had docking stations for years which use one connection, so arguably (and profitably for lawyers...) claim 1 is invalid.
Speccies were fanless, I'm pretty sure. I don't recall fan noise from one and I had mine open periodically (I was that kind of kid....).
As for the heatsink, surely someone has used the enclosure as part of heat dissipation before?
Pretty much... "Sign here and get a guaranteed payout and go away. Or take it to trial, where our lawyers are better paid and you might get nothing and have to pay our legal fees. Your call...."
Not hard to see why they might just take the settlement and sign the NDA. There might come a time that someone is willing to take it to court on principal, but it'll take strong principles and dedication to go through it all.
IBM would, of course, argue that they're just minimising risk and seeking closure to the whole thing and just trying to save their ex-employee from a gruelling court case.
"it mysteriously disappeared from the disk and its backup did not work either." - so they had a backup, presumably on a second floppy; these are the days when code could fit on a single floppy after all. My guess is the first copy nuked itself, so they loaded the 2nd copy into the PC and ran it with the same result.
In house IT teams will generally put in a bit more effort to keep things ticking over; it's in their interest, after all, since it's job stability, performance bonuses and share options in many cases. Outsourced IT workers will generally do the minimum required to meet the SLA and service improvements won't happen unless it's billable (at an appropriate markup, obviously).
RAID is fine, up to the point it takes so long to rebuild the replaced disk that another disk fails in the meantime. I think we got to the point that RAID 5 was no longer "good enough" because the chance of hitting a 2nd disk failure during a rebuild of the parity was pretty near 1 on large storage arrays some time ago...
There are a bunch of reasons to replace servers:
Harder to get hold of replacements. No-one's making 5 year old CPUs as a rule (although I daresay AWS may have contracts with Intel/AMD etc to supply CPUs for a longer period) so maintaining a big enough fleet of server type A becomes too hard and you have to retire them and replace with server type B.
Technical debt - keeping your stack running on old kit means one more piece of tin to support so you have to retire it as new kit comes in and replaces it.
Marketing - if your cloud is using 5 year old CPUs and competitor is using 1 year old CPUs, which cloud are you going to use?
Power/cooling. New CPUs are often more efficient than older ones, so there are cases it's worth replacing old CPU models with newer CPUs. They probably don't have a much higher clock speed (if at all), but probably have higher core count so you can gain significant savings in footprint, power and cooling with newer CPUs.
As for impact on life of running in the cloud, I'd imagine they're mostly running hotter all day than on-premises kit; I don't know if that impacts their running life more than the warmup/cooldown cycles of on-premises.
I have said it often - some people in America would vote for a dead goldfish, provided it was standing under the correct party. Sometimes it's because they've always voted Republican/Democrat, sometimes it's just because the goldfish wouldn't be the "other person".
There's a cut-off point at which you're better replacing older servers because the hardware cost is made up pretty quickly in reduced footprint/power costs. If you're running 6 year old servers with 6 cores/socket, you can probably half your running costs with a newer 12 core CPU because you'll get twice as many cores in each rack.
For a standard company, you often have to reckon in the project costs of doing such a replacement and getting budget approvals etc, and that's before you potentially get into licensing issues with replacements. If you're used to simply swapping out boxes on a daily basis and your software stack is free/internal, it becomes a much cheaper option to replace old kit, so that breakpoint of saving money happens sooner.
While at university in the mid 90s, my mate and I were doing some work and needed to FTP a file to/from one of the servers, so we opened up the supplied FTP client (stored on a Novell fileshare IIRC), typed in the server name and found an auto-completed config set for that server. With the root account. And a password saved in the config. We looked at each other and hit "connect"... and promptly had an FTP session on the server as root.
After confirming we were definitely in as root (by downloading, deleting and re-uploading /etc/passwd - yes, a bad choice in retrospect, we could have FUBAR'd the machine), we decided we'd better tell the lecturer who looked after that box about the issue. The config in the FTP client was removed that day.
Why do we care about this bug that allows a user to run unprivileged code? It couldn't possibly be used to do anything nasty...
The point is that once you have an unprivileged shell on a target machine, having a method to escalate to root is the next step. The best crackers don't rely on one vulnerability, they chain together multiple vulnerabilities to get where they want to be.
Handful of reasons:
1. Legacy. 10 years ago, if you wanted a robust, vendor supported DB solution, Oracle was one of the few shows in town. This makes for a lot of systems deployed on Oracle
2. Inertia. Once you have 100s of DBs on Oracle, it's harder to introduce another one. Many companies will have a policy like "all databases to be Oracle" because they've standardised on it.
3. Features. Oracle does have some features that are rare in other products. Probably >95% of DB use cases will never use any of those features, but if you need feature X, you really need it.
4. Application vendor support. "We support our application with Oracle DB" means you pretty much have to deploy Oracle if you want it to work. For some of these applications, there may not be a replacement which supports PG/Maria and is "good enough".
I strongly suspect that 90% of Oracle databases could well be managed with PostgreSQL, MariaDB or whatever quite happily with negligible development work, but the legacy and inertia issues mean they're stuck on Oracle.
Oh, yeah, the 6 monthly reinstalls were painful, but better than the instability & slow downs you got after a few months. XP was the first version which I managed to leave for over a year between reinstalls I think.
As for shenanigans with autoexec - my first PC (DOS/Win 3.11) had to have the boot interrupted to run Doom, otherwise it didn't have enough memory (a measly 4MB). I have vague recollections of tweaking both files at different times, but generally just left them well alone as far as possible...
Latency and the speed of light. Basically, AWS runs "Regions" (e.g. eu-west-2 is somewhere around London) in which are multiple "Availability Zones" (i.e. data centres). If your data centres are too far apart, you'll start hitting latency issues with certain services which replicate data within a region, so you need to keep them relatively close together to remain performant.
As you've rightly pointed out, this does entail keeping them in the same "blast radius" of certain events which is why you should be looking to have a DR solution in another region to cover for the rare cases of an entire region going out. That said, the more common event is a networking/maintenance SNAFU which takes out a region rather than natural disaster.
I've done some training on AEDs as part of First Aid at Work training and I was shocked (pun intended) at how simple they are to use. I've not seen one with videos, but the diagrams on the pads make it easy to know where to put them and the device will tell you what to do.
Also, as far as CPR goes, if someone isn't breathing, you CANNOT make them worse by attempting CPR. At worst, their corpse might have a few broken ribs (common rule of thumb is "if you don't break a rib, you're not doing it hard enough), but they'd be dead anyway. At best, you'll keep their organs oxygenated long enough for medical attention. Bad CPR is better than no CPR.
One = mean assign, two means comparison. As to why that was done way back when, I don't know for sure. It does mean that both of these are valid in C although they behave differently (in most cases):
if ( x = y ) // assigns value of y to x, checks if that is true or false (true=0, false anything else IIRC - it's been a while)
if ( x == y ) // compares x to y, doesn't change value of either
The fact that the top option works and will compile must have been the source of millions of bugs in C programs over the years. I will note that, for my sins, I have used the method of assigning a variable in an "if" statement intentionally (in Java, FWIW, although the methods are the same) and the code worked as expected.
Oooh, even numbered service packs... I was in a Windows training course in the late 90s and the instructor pretty much said that even numbered service packs were of low quality. SP1 fixed the problems in initial release, SP2 was broken, SP3 fixed those problems before SP4 would break again. IIRC the same applied to Windows 2000.
Normally, if two insurance policies cover an incident, both pay out a portion of the payout. I guess if one policy says "no payout if another policy covers the incident", it wouldn't apply and the other insurance pays out. What happens if both say the same thing would be interesting as you could argue neither apply...
It's probably down to how you can register other apps for core services - like FB messenger keeps nagging and trying to take control of SMS messages ("Unified interface for all your messages", totally unrelated to slurping up as much data as we can for advertising...). It's potentially really useful to have an alternative app for making phone calls (possibly with accessibility features for some users), but that application must NEVER interfere with making emergency calls. It should also be crystal clear that it's taking on that role so the user understands what's going on.
Best guess is that the issue is Teams app trying to register as a way to make/receive calls (since you can make calls with Teams) and screwing it up.
Seems to be a theme of Netware boxes running happily in odd places without any issues: https://www.theregister.com/2001/04/12/missing_novell_server_discovered_after/
Use of Amex is still flaky; a lot of stores don't accept mine so I have to use another card. Annoying (particularly as mine gives me cashback on purchases), but I just shrug and pull out another card.
Visa/Mastercard pretty much have a duopoly on card transactions, so it would be interesting to see if Mastercard start ramping up their fees too where shops would go after that.
Yeah, our LG smart TV effectively became a dumb TV a few years back when the the apps (Youtube etc) didn't get updated to work with new protocols. The Sky Q box does all the "smart" functionality now and rendered the Fire TV stick and Chromecast somewhat redundant.
Biting the hand that feeds IT © 1998–2022