Posts by An_Old_Dog 3470 publicly visible posts • joined 26 Mar 2010
DoGE has effectively purged institutional technical knowledge from the departments it has touched.
The newbies won't know WFL, ESPOL, or how to use a CRT terminal ("Where's the mouse?"), let alone why there is an old, still-in-use Burroughs computer in the department's data center.
Workers are more-likely to out in extra effort to make a deadline when that deadline was not due to incompetent and/or don't-give-a-fuck management.
Y2K is a great example of that. The deadline was known for years in advance by management. We were working crazy hours. I made much-more in overtime pay alone that year than I did in regular pay. By starting our Y2K work a year earlier, they could have avoided the need for overtime Y2K work.
Without the overtime pay, I would have declined to work those extra hours.
At uni, two different mainframes I worked on there did not have CPU-priority based queues, but had time-of-day based queues.
There was Prime (day) shift (orange job card), Secondary (evening) shift (blue job card), and Tertiary (night) shift (green job card).
Most of the time, prime shift turnaround was 2-3 hours, and evening shift turnaround was about 1.75-2.5 hours. The mainframes were unavailable during the DAYEND-and-maintenance 1AM-4AM period. The operators went home at 1AM, and returned at 6AM. While the computer center was physically-open 24/7, you could not get your card decks and printouts back unless the operators were on-site.
Smart and frugal students would submit their batch jobs to the evening and night shift queues, arrange for their outout to be dumped to a file, look at that file on a terminal, and print the file on a line printer or printing terminal if the output was "good".
With many-fewer jobs in the evening and night queues, they ran real-time faster.
That all went out the window at the end of the term when many people were doing last-minute programming for their classes. Both mainframes would be overloaded by the number of simultaneous time-sharing users, and response time became abysmal.
Doyle said that the airline expects to rely increasingly on partners and vendor platforms to help curate its digital presence
We don't know what we're doing in re agentic AI, so we're outsourcing our reservation systems to some company which also doesn't know what it's doing, but has convinced our board of directors that it does.
When I was in high school, I had an idea like this. Write bits by 3 lasers shooting into *some* sort of medium, which only changed when the power was high enough -- when all 3 lasers converged on a point.
The problem I couldn't solve was, "how do I read a bit without the intervening bits on the axis of each laser interfering with the signal?"
The same question applies here. How do they read the strength of the light reflected from the selected bit without the absorption and diffusion of that reflected light by intervening bits from causing inaccurate results?
They may have solved this problem, but TFA did not tell us what that solution was.
The could-have-yet-did-not syndrome has a three-character name: "Y2K".
Temporary and pernanent electronic and magnetic storage was very expensive in the 1950s and 1960s when these systems were designed, and their cost/performance/flexibility tradeoffs made.
Yet when storage costs did plummet, executives chose to not revisit those tradeoffs.
The assumption/presumption in replacing a bunch of old systems with a new, does-all mega-system, is that the new system, which must incorporate all the functionality (and consequent bug-breeding grounds) of the collection of old systems, will be somehow more-reliable.
The reason these companies and institutions ended up behind the eight-ball with their systems is that they did not budget-and-spend programmers' time on updating all the little systems, on a continuous basis, to solve problems such as, "The data is stored in fixed-field, 80-column records, so we can't add a new field without both taking space away from some other field(s), creating and running a data migration project, and modifying every one of our RPG II programs which create reports based on the old data format."
Converting to a new system requires a re-implementation of all those RPG II reports. Or accepting less functionality from the new mega-system.
* Shout-out to that fine, old Canadian rock band, Bachman-Turner Overdrive.
I have never needed a spreadsheet in the six decades-plus of my life.
I have created and used them for some of the same reasons many other people do so:
* they're fast to create vs "real" programming;
* they have a built-in data presentation model which most people can get their heads around;
* they work well-enough for small amounts of data; and,
* using them is faster than doing things with a paper spreadsheet and a calculator.
Those advantages do not in themselves make spreadsheets "good", in the same way that eight-sided cart wheels are better than square cart wheels, but still are not "good".
The reason so many people think they need spreadsheets is that they've never been taught any other way.
... I realized Watchtowr was missing the 'e'.
Hmm ... a quick check of the web shows all JW-related-links which I glanced at showing the correct spelling.
Perhaps you saw a one-time printed-version typo.
Perhaps the JWs had contracted an "image consultancy" which recommended they drop the 'e' in "Watchtower" -- until a bunch of older JWs wrote to the head office that the new makeover "makes us look like a bunch of illiterate morons."
I went round and round with a user complaining sbout a blank screen for a few minutes until they eventually said, "I'm looking at a blank screen. It says, 'Press any key to continue' at the bottom."
That taught me something about TUI interfaces, and how I should design them differently in the future, even if it's "just" in an MS-DOS batch file.
"... it is important to focus on the core vision set forward by Broadcom, which is to be a private cloud platform provider, not just being a hypervisor company”
No, it is not important for customers to focus on executive 'visions' distracting from the true issues.
It is important for wise customers to focus on the quality, security, corporate strategy, and price of their vendors' offerings.
COBOL and FORTRAN back then: easier than machine language and assembly language.
COBOL and FORTRAN today, with object-orientation and a giant grab-bag of other features added in: perhaps not easier than the machine languages and assembly languages of back then, but probably easier than the machine languages and assembly languages of today. (Intel's errata for modern x86 chips is longer than then entire MC6800 programming manual. Seriously.)
electric vehicles are also more likely to have better safety technologies than most internal combustion engine vehicles on the road today, which help them to evade crashes or limit impact, the authors argue.
What would theae "safety technologies" be which putatively "help them to evade crashes"?
Do they have an AI overseer which yanks the steering wheel and/or applies the brakes to avoid a pedestrian?
Visio cares, because if Visio made their source (and all other information needed to build, install, and run their software), the first thing people would do is modify that software to strip out all the data-thieving/phone-home features.
Visio fears a loss of revenue they orherwise would get from the sale of that purloined data.
@ Eric 9001:
"withhold the necessary compiler, assembler, linker, and run-time engine flags" violates multiple freedoms, but it at least violates "plus the scripts used to control compilation and installation of the executable" - as without those flags, you cannot compile and install the executable.
Does GPL version-whatever literally say that you have to provide source code to everything necessary to build and install the product? I'm not writing about intent, I'm writing about the literal text, because that is generally what the courts look at.
If GPL version-whatever does not literally say that, then Vizio can legally keep their flags and their source to Billy-Bob's Binary Builder as their secret sauce, and the end-users are shit-out-of-luck.
I now expect Vizio to say, "Okay, fine. Here's all our source code," and to provide all that souce code ... and withhold their internally-used code for Billy-Bob's Binary Builder, and to withhold the necessary compiler, assembler, linker, and run-time engine flags. They'll also not specify which compilers, assemblers, linkers, and run-time engines they used, or the version numbers of those programs.
Good luck getting their provided code-wad to build and run correctly.
But hey, they will have complied with the letter of the law.
32-bit support is not "fat" to those of us with 32-bit machines! To the obvious question of, "why don't you upgrade your hardware?" the answers are:
#1: Modern laptop keyboards suck like bilge pumps. The keyboard is the user's primary computer input vector, and is the user's most-important productivity -- though far-too-frequently, anti-productivity -- tool. It's a major pain point. Modern laptop keyboards have half-sized function keys and arrow keys. They have badly- and arbitrarily-placed logo, menu, and "Fn" keys (I'd like to have those keys, but have them samely-placed). They have extremely-short travel (in service of the fashionista god, "Thinness").
#1b: Carrying an external, good keyboard is just one more thing to juggle when you're packed into an auditorium chair at a conference or event. The utility of a laptop comes from having just one thing to carry.
#2: Upgrading would involve throwing out perfectly-working devices. I hate planned obsolescence and the landfill economy; I wish to fight it by continuing to use functioning older things (and repairing them when needed, when possible, and when economically-sensible).
after working with team members who are in maybe 1 daily meeting per week due to connection issues
Channel your inner BOFH and you will understand: some (many?) of those "connection issues" are artificially-induced to reduce the number of pointless meetings, or meetings with undesireable people and/or issues, which the remote attendee "has" to attend.
Presumably for job interviews, the candidate truly wishes to attend.
If we spend the money on increasing security it may prevent a breach sometime in the future. If we spend the money on extra clinical staff hours it will prevent a death in the next few days.
1. If a business or organization is so underfunded that that choice -- security vs near-immediate patient death -- is truly binary, they should not be in business/operation.
2. A security breach of a medical organization's computers can lead to many deaths.
@Liam Proven:
After reading the article, I thought, "Neat use of Optane. But isn't Optane some kind of fast flash memory? [I didn't know the particulars of Optane] Is it subject to write-cycle wear, as is flash memory? I should find out."
I then DuckDuckGo'd Optane wear-levelling and got Intel's explantion of Optane wear-levelling, which I partially-reproduced in my comment. If you go to the URL I listed, you will see a large-font headline reading, "Protect the Lifespan of Your Intel® Optane™ Solid State Drive".
After reading Intel's article, I naturally came to the conclusion that write-cycle wear on Optane is a significant issue.
Whether Optane is installed into a quasi-drive, or in DIMMs does not alter the underlying technology; both forms will share the same limitations, flaws, etc.
Thus, I wondered whether dm-pcache had a [hopefully-optional] policy which would leave some cache memory (whether pseudo-disc or pseudo-RAM) unused, so that Optane-used-as-cache could properly wear-level itself.
You asked why a cache failure would be a problem.
The problem is that corrupt data can replace your "good" data living on permanent storage.
This would happen is if the data were corrupted in-cache, after a write-to-disc command had been issued by a user's program, yet before the data had actually been copied from the cache to the disc.
From Intel's info:
"Keep some space open
Although read/write cycles rarely cause problems with your drive, there are measures you can take to ensure they don't. A technology called wear leveling makes your computer write equally to all available spaces on your SSD. Wear leveling keeps storage cells in your SSD from wearing out faster than other cells.
You can only use wear leveling on open cells. [Intel's emphasis] If a cell in your drive is used for long-term storage, you force the drive to reuse other cells when it needs more space. Reusing other cells increases the read/write cycles on those cells faster. Open up storage on your drive for wear leveling by:
Deleting unused files on your computer.
Moving unused files to an external hard drive for long-term storage."
https://www.intel.com/content/www/us/en/support/articles/000023410/memory-and-storage.html
(The above-quoted Intel web page is specifically about Optane drives.)
With that said, how much space is kept unused ("open") on a caching Optane drive under dm-pcache?
Improved effective disc speed at the price of (silent?) data corruption when a flash drive fails is a dog's breakfast.
LLMs do not reason. Their promoters indirectly lie that they can. This lie has been repeated all-too-many times.
Matt Garman lies in this quote: "...without losing the important foundational capabilities of the model, like reasoning."
These models do not reason.
Tobias Mann lies in this statement: Lite and Pro are reasoning models...
These models do not reason -- regardless of how many times The Reg and other publications publish articles implying that the models do reason.
I believe there is no technological navigation system which depends upon radio which cannot be jammed (possibly, and/or spoofed).
In this age of techno-assholes, you are going to have to, for the sake of flight safety, accept a return to navigation by manual methods (if inertial navigation systems are too expensive and/or are too inaccurate) and takeoffs and landings via the Mark I human eyeball.
This in turn means some takeoffs will have to be delayed, and some landings prohibited/re-routed to alternate airports under excessively rainy, foggy, snowy, or smokey conditions.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
