software situation

Although 99.9999% of all "We have the programmers" SPAM offers web programming, there is still good old firmware and embedded development. It is in just remaining 0.0001% but it is not a Java/dotnet/golang/etc junk coding area and still requires skills/experience/knowledge.

All, sorry for an expletive, Facebook and such "software" is a huge stinking heap of manure that can (and should) be replaced with automatic junk generation so that entire legion of so-called "programmers" will be out looking for some kind of meaninful and productive job.

However, it will still take some people with the brains to make that automation happen.

Isaac Asimov, "Profession" (1957) -- highly recommended reading.

There's mostly nothing wrong with all the good old software.

Ross Finlayson snipped-for-privacy@gmail.com wrote:

Yep, _MOSTLY_ nothing wrong with the _GOOD_ _OLD_ software.

Just compare old LSI 3dm2 RAID web software (single file, relatively small, full control over RAID arrays, doesn't require root login, no need for a web server or whatever else, just run it) and the current LSA monstruoso with separate web server, tons of [Java] code, tens of files, numerous libraries, constantly failing requiring service restart, most of the values nailed down and config files re-written every time it starts, writing tons of totally bogus and 100% useless logs and so on. And those "programmers" (as usual a small team of just several hundreds of "Java programmers" of Indian descent) don't have a clue what Unix is -- they write all that crappy logs to /opt where that monster is installed. They devinitely never heard of /var/log or other places in Unix. Their command line utility craps whatever directory you're in with huge totally useless logs unless given a "nolog" option so soon your entire FS is crapped with those logs. They probably never heard that a logical behavior is exactly opposite -- if one needs that log he should explicitly ask for it with kinda "log" option... But hey, it is not a stupid LSI anymore, it is a BIG ADVANCED Broadcom that simply can't allow itself to do something simple and useful... And BTW their WEB software is even more horrible -- just try to find the latest LSA monster that works with your RAIDs... It is just an unsorted heap of everything that one has to sift through to find that pearl in the pile of manure. And then spend a lot of time fixing that crap, pardon my French, to make it work somehow...

Their RPM package "install" is a separate horror story -- they never learned what _A_ package manager is, not even starting on RPM in particular...

COBOL is being likened to the asbestos cleanup.

See the article:

Right, many of them won't be needed. AI will be much more than just a tool to replace people. It will enable systems beyond the comprehension of any human. For now, it seems the AI science is struggling with what they call the interpretability problem, by which they mean figuring out the algorithm used by the AI entity. It's no mean feat and they really go to extremes doing this in even the simplest cases. Just because they trained the model, it doesn't mean anyone knows how the AI uses that training. They have made some interesting discoveries, such as training the AI with contradictory precept knowledge results in an entity that's certifiably insane and/or evil. The European Center for Medium Range Weather Forecasting has an AI model that takes 5 minutes to duplicate the same forecast as their massively computation-intensive center takes 12 hours to do. But they refuse to use it because they don't know how it works, and it's of utmost importance that their forecasts remain reliably accurate..

The problem is that people are terrified of touching something that *seems* to be working. So, keep glomming crud on and around it to add perceived functionality and/or featurism.

BIOS "setup" modes now try to look like a Windows GUI -- for something that is seldom used! Features are wedged under AND over existing mechanisms without a true understanding of what the mechanism is actually doing and the assumptions under which it *actually* operates (as the assumptions under which it was DESIGNED to operate are likely not formalized anywhere!)

You have non-technical *business* people making TECHNICAL decisions (e.g., "let's use this FOSS software as a base to save all of those development dollars") and non-business *technical* people making BUSINESS decisions (e.g., designing the UI/UX because the business folk are clueless as to what is possible and how things SHOULD work).

Ah, but look at how fancy the interface can *appear* -- all without writing much *real* software! We just hack together some web pages on an HTTPd that we stole from some repository and we're done!

Imagine designing an AM/FM radio by taking an AM radio and GLUING it to an FM radio with a DPDT switch feeding the speaker output. Then, wrapping the beast in a big plastic case...

If both designs were already in existence, you would think this a wise move as those already *work* and it's easy to imagine adding a DPDT switch -- what could go wrong? Surely, this is much easier to develop than trying to build *up* both, from scratch, in a single enclosure? (??)

Look at existing software products and see how much cruft has been

Imagine the quality of code you'll get from an AI trained on such crap!

Nah, it is a big corporation style... They don't need brains, droids are better. Brains have no value -- "time to market" and "established procedures" (latter allowing numerous management positions, kinda like 5 managers reporting to each other per every person actually doing something) is way more important.

Here is my favorite very old parable (sorry for a long post):

=== Cut === The Hidden Costs of Toast Technology

Day 1: My boss, an engineer from the pre-CAD days, has successfully brought a generation of products from Acme Toaster Corp's engineering labs to market. Bob is a wonder of mechanical ingenuity. All of us in the design department have the utmost respect for him, so I was honored when he appointed me the lead designer on the new Acme 2000 Toaster.

Day 6: We met with the president, head of sales, and the marketing vice-president today to hammer out the project's requirements and specifications. Here at Acme, our market share is eroding to low-cost imports. We agreed to meet a cost of goods of $9.50 (100,000). I've identified the critical issue in the new design: a replacement for the timing spring we've used since the original 1922 model. Research with the focus groups shows that consumers set high expectations for their breakfast foods. Cafe latte from Starbuck's goes best with a precise level of toastal browning. The Acme 2000 will give our customers the breakfast experience they desire. I estimated a design budget of $21,590 for this project and final delivery in seven weeks. I'll need one assistant designer to help with the drawing packages. This is my first chance to supervise!

Day 23: We've found the ideal spring material. Best of all, it's a well-proven technology. Our projected cost of goods is almost $1.50 lower than our goal. Our rough prototype, which was completed just 12 days after we started, has been servicing the employee cafeteria for a week without a single hiccup. Toastal quality exceeds projections.

Day 24: A major aerospace company that had run out of defense contractors to acquire has just snapped up that block of Acme stock sold to the Mackenzie family in the '50s. At a company-wide meeting, corporate assured us that this sale was only an investment and that nothing will change.

Day 30: I showed the Acme 2000's exquisitely crafted toastal-timing mechanism to Ms Primrose, the new engineering auditor. The single spring and four interlocking lever arms are things of beauty to me.

Day 36: The design is complete. We're starting a prototype run of 500 toasters tomorrow. I'm starting to wrap up the engineering effort. My new assistant did a wonderful job.

Day 38: Suddenly, a major snag happened. Bob called me into his office. He seemed very uneasy as he informed me that those on high feel that the Acme

Day 48: Chuck Compguy, the new microprocessor whiz, scrapped my idea of using a dedicated 4-bit CPU. "We need some horsepower if we're gonna program this puppy in C," he said, while I stared fascinated at the old crumbs stuck in his wild beard. "Time-to-market, you know. Delivery is due in three months. We'll just pop this cool new 8-bitter I found into it, whip up some code, and ship to the end user."

Day 120: The good news is that I'm getting to stretch my mechanical-design abilities. Chuck convinced management that the old spring-loaded, press-down lever control is obsolete. I've designed a 'motorized insertion port', stealing ideas from a CD-ROM drive. Three cross-coupled, safety-interlock micro switches ensure that the heaters won't come on unless users properly insert the toast. We're seeing some reliability problems due to the temperature extremes, but I'm sure we can work those out.

Day 132: New schedule: We now expect delivery in three months. We've replaced the 8-bitter with a Harvard-architecture, 16-bit, 3-MIPS CPU.

Day 172: New schedule: We now expect delivery in three months.

Day 194: The auditors convinced management we really need a graphical user interface with a full-screen LCD. "You're gonna need some horsepower to drive that," Chuck warned us. "I recommend a '386 with a half-meg of RAM." He went back to design Revision J of the PC board.

Day 268: New schedule: We now expect delivery in three months. We've cured most of the electronics' temperature problems with a pair of fans, though management is complaining about the noise. Bob sits in his office all day, door locked, drinking Jack Daniels. Like clockwork, his wife calls every night around midnight, sobbing. I'm worried about him and mentioned my concern to Chuck. "Wife?" he asked. "Wife? Yeah, I think I've got one of those and two or three kids, too. Now, let's just stick another Meg of RAM in here, OK?"

Day 320: We gave up on the custom GUI and are now installing Windows CE2e. The auditors applauded Chuck's plan to upgrade to a Pentium with 32 Mbytes of RAM. There's still no functioning code, but the toaster is genuinely impressive. Four circuit boards, bundles of cables and a gigabit of hard-disk space. "This sucker has more computer power than the entire world did 20 years ago," Chuck boasted proudly.

Day 384: Toastal quality is sub-par. The addition of two more cooling fans keeps the electronics to a reasonable temperature but removes too much heat from the toast. I'm struggling with baffles to vector the air, but the thrust of all these fans spins the toaster around.

Day 410: New schedule: We now expect delivery in three months. We switched From C++ to Java. "That'll get them pesky memory-allocation bugs, for sure," Chuck told his team of 15 programmers. This approach seems like a good idea to me, because Java is platform-independent and there are rumors circulating that we're porting to a SPARCstation.

Day 530: New schedule: We now expect delivery in three months. I mastered the temperature problems by removing all of the fans and the heating elements. The Pentium is now thermally bonded to the toast. We found a thermal grease that isn't too poisonous. Our marketing people feel that the slight degradation in taste from the grease will be more than compensated for by the "toasting experience that can only come from a CISC-based, 32-bit multitasking machine running the latest multiplatform software."

Day 610: The product shipped. It weighs 72 lbs. and costs $325. Chuck was promoted to CEO. === Cut ===

I still program in asm (for Microchip PICs for example), and it does make very efficient use of the hardware.. Control my drone with it.. Big software language babblers need big machines that weight a lot, use a lot of power and are more easily infiltrated if not even from the start. All that increases sales, Billy the Gates buys shares in hardware companies and then makes ever more bloat so people have to buy new bigger computaahs with every new version of double glazing windows. New computaaah languages are created every day C was OK, C++ a crime against humanity, and pye-toon snake language for the idiots. BASIC was fun too!

OK, ask AI in Your language to write the code for anything... Add a budget limit for the hardware.

Keep dreaming..

Many years ago US did a manned moon return with less computer power then a modern smartphone. Look at the US now, NASA postponed Moon landings again,, Not even a flawless return from Earth orbit SpaceX postponed its Mars plans.

Did they ask AI???

Start with the *****!!!!!****BASICS learn the hardware and outperform that AI anytime.

Don Y snipped-for-privacy@foo.invalid wrote: |----------------------------------------------------------------------------| |"The problem is that people are terrified of touching something that *seems*| |to be working. So, keep glomming crud on and around it to add perceived | |functionality and/or featurism." | |----------------------------------------------------------------------------|

"Title: The Computer Revolution Hasn't Happened Yet Location: Atlanta, Georgia Talk by: Alan C. Kay Date: [1997-10-05, 1997-10-09] Transcript by: A. R. Svendsen (started 2007-09-30) Transcript release: 1 (published 2007-12-30)

Now, somebody could come along and look at this dog house and say, Wow! If we could just expand that by a factor of a hundred we could make ourselves a cathedral. It's about three feet high. That would give us something thirty stories high, and that would be really impressive. We could get a lot of people in there. The carpenters would set to work blowing this thing up by a factor of a hundred. Now, we all know, being engineers and scientists, that when you blow something up by a factor of a hundred, its mass goes up by a factor of a million, and its strength, which is mostly due to cross sections of things, only goes up by a factor of ten thousand. When you blow something up [by] a factor of a hundred, it gets by a factor of hundred weaker in its ability, and in fact, what will happen to this dog house; it would just collapse into a pile of rubble. Then there are two choices you can have when that happens. The most popular one is to say, Well, that was what we were trying to do all along. [Laughter] Put more garbage on it, plaster it over with limestone, and say, Yes, we were really trying to do pyramids, not gothic cathedrals. That, in fact accounts for much of the structure of modern operating systems today. [Laughter and applause]

|------------------------------------------------------------------------------| |"[. . .] | | | |> Just compare old LSI 3dm2 RAID web software (single file, relatively small, | |> full control over RAID arrays, doesn't require root login, no need for a web| |> server or whatever else, just run it) and the current LSA monstruoso with | |> separate web server, tons of [Java] code, tens of files, numerous libraries,| |> constantly failing requiring service restart, most of the values nailed down| |> and config files re-written every time it starts, writing tons of totally | |> bogus and 100% useless logs and so on. | | | |[. . .]" | |------------------------------------------------------------------------------|

An ex-workmate used to be the administrator for a RAID. He sensibly cautiously used not rely on it to its extreme boast lest there is "a bug in Linux." is how he phrased it.

|-------------------------------------------------------------------| |"Look at existing software products and see how much cruft has been| |*dragged* along for the ride -- that isn't strictly necessary. | |But, determining what *should* be present requires thought and | |planning and the ability to gauge the complexity of said task(s). | |Much easier to see the world as just piling more crap on something | |that you THINK gets you a head start! | | | |[. . .]" | |-------------------------------------------------------------------|

I am a space scientist. I used to be a space-engineering student when I was enrolled in Module 'Principles of Space Instruments'. This module includes a team project to make a proposal for designing a mission. (This project does not actually entail really making a finished design - it is just a part of 1 module, so it is not even a thesis.) I am the only computer scientist who was in this team, so I am responsible for the computers part of this proposal. Triply modular redundancy is a normal paradigm for computers on spacecraft. I insist on this project's redudnant computers not being beside each other, because if one would become overheated or would similarly crap out, then its neighboring computer would immediately crap out likewise. This team's leader concluded that it would be ironic if a redundant neighboring computer would crap out because the redundant safety mechanism would not be safely located. If only all leaders were so appreciative of intelligence! Our team is the only team to get a grade of 100% in this project assignment in 2 years. (S.

I can't comment on big teams as the largest project I've worked on was only 30 souls (and, the guy running the project hadn't realized that he needed a person -- not me -- to write the software for the microprocessor

-based product they were designing! <rolls eyes> He could "imagine" all of the mechanical and electronic stuff but failed to see the role the software/firmware would play)

The greatest number of software people I've worked with on a project was three. And, everything was /ad hoc/ between us (no management).

OTOH, I often work on FOSS where it is obvious that dozens/scores of eyes have been involved. But, FOSS gives you the luxury of taking ownership of it for your own purposes and not requiring the consent/approval of anyone to make your own specific changes!

Having said all that, it's instructive to think about how you approach a (significant) piece of code; how aggressively do you attempt to understand it -- ALL of it -- before tinkering? How *sure* are you that the effects of your tinkering are localized and don't have "distant" ramifications?

Instead, you glom layer after layer onto something instead of stepping back to see if what you want/need isn't more readily available *within* the existing codebase.

Hardware is easy to pick up, get an appreciation for and determine how (if) a particular change can be made. Software is far more opaque. Easier to just keep adding layers on to get the functionality you want -- more bloat, more dubious performance.

Nowhere is this more obvious than in OS design -- as if every OS tries to be "all things to all applications"... and, is woefully inadequate in being anyTHING to anyONE. (do you really think you can back-port real-time constraints to an OS that was designed without concern for them? Or, a robust capability system layered on a system that doesn't inherently support same?)

Just how big (bloated) does an OS have to be? How much cruft do you embrace for the sake of claiming you can do it all?

SWMBO bought a toaster some years ago (she has toast each morning). I laughed at how "over-designed" it was -- 5 or 6 buttons, LEDs, a "darkness setting", tone to announce completion, etc.

And, how obviously it had traded feedback from the toasted item ("doneness") for an open-loop time-based control.

OTOH, amazing that this was likely the most economical approach to the problem!

OS designers like to delude themselves into thinking every application can be hosted on THEIR OS. Like a car manufacturer thinking the ONE model that they produce can meet the needs of a family of four, a tradesman, a delivery company, an ice cream vendor, etc.

Granted, it can provide "transport" to each of those -- but, likely not a well fit to ANY of them.

This is exacerbated when that company keeps glomming on features to their STANDARD PRODUCT in an attempt to *try* to meet all of those expectations. It makes any one application that much less of a good fit as it now carries excess baggage that doesn't add value for THAT application.

IEEE 754 defines a way of handling mathematic operations. Why isn't it the SOLE approach to those? Why do we still use integers when we could be using 80 bit floats for EVERYTHING? Maybe we should modify the 754 standard to include a type of "float" that is actually an integer?

The fallacy of RAID is that the larger the array, the more likely a *second* fault manifests while attempting to recover from the first. It's like having gold speaker wires -- something to brag about that has no real value in most cases.

Or, a micrometeorite passes through all three adjacent devices.

I was tasked with enhancing an existing product -- within the hardware constraints that were already in place. This meant getting a good feel for everything that was happening "under the hood" as I would have to figure out how to replicate the current behavior AND incorporate the new functionality with the same resources that were available (space, time).

There was a 128 byte structure buried in the design implemented triply redundantly. *AS* three structures having identical values located in contiguous blocks of memory.

The number of ways that such an approach could fail that could not be reliably detected (e.g., address failure, device failure, etc.) was laughable. And, the recovery algorithm was poorly conceived (what if no two copies agree COMPLETELY? Do you install a default value? What should that value be? If predictable, then this is an attack vector...)

This is the same mentality behind folks adopting RAID or ZFS needlessly. They don't think their decision through and, instead, convince themselves that they have taken concrete measures to improve the reliability of their data! (how often should you do a patrol read? how do you respond to errors detected/corrected? what criteria do you use to retire media? do you support a hot spare? how many??)

reliably

Refuse?

ECMMWF forecasts have been available online for about 4 years.

It's also the primary forecast for sites such as

You can compare other computer forecasts at the bottom of the page with GFS, ICON, MeteoBlue, NAM and HRRR:

If you're concerned about accuracy, try:

reliably

Weather forecasts will never be very accurate. The atmosphere is highly chaotic.

If you see a giant weather front bearing down on you, you can usually predict tomorrow's weather. Predictions a month ahead are worthless.

No amount of AI will help.

Around here, on the US west coast, weather forecasts are mostly amusement.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Yep. What is often ignored by is the atmosphere has layers. The public is mostly interested in what happens near ground level. Airplane pilots care about altitude, but they have their own specialized forecasting system. Windy.com has a slider for adjusting the altitude in the animated map. Move the slider back and forth and you will see some rather spectacular changes in wind direction and force.

Predicting that tomorrows weather will be the same as todays weather is correct for about 70% of the time (my estimate). Predictions a few days ahead, also known as "outlook", are best predicted by climate models. For example, NOAA considers 6 to 10 and 8 to 14 days ahead as climate:

Well, AI will speed up the generation of wrong answers.

I view AI as a calculated consensus with a convenient conversational interface. For example, there's an AI for calculating the consensus of peer reviewed research papers: <https://consensus.app>Never mind that the experts and the consensus are often wrong:

I've attempted to generate my own weather forecasts in the past and failed miserably. The problem with the California left coast is that weather systems do not follow a straight line path when crossing the coast. My guess(tm) is it's caused by refraction due to changes in air density with temperature change as the weather system crosses the coast.

Gotta run or I'll be late (again).

Term-rewriting systems and term-graph re-writing systems offer accounts of translation of sources then for accounts of rewrite systems generally about extracting "the logic" with regards to models of computation with process models and resource models, then as with regards to usual accounts of libraries like BLAS (basic linear algebra subroutines) and why FORTRAN and C have essentially different concepts of "array".

The old superscalar approaches of the large register word vis-a-vis the modern commodity hardware of the general purpose computing and its account of many-core, make for intuiting how to express the intent of the original sources with regards to architectures.

"Java" isn't bad, these days it's so that lots of the "old perfect code" is written in Java, then for example as above that "it's just code".

It's agreeable that the "embarrassment of resources" of modern systems mean that a lot of recent code is a model of inefficiency.

"POSIX", is usually considered the standard.

Most accounts of C/C++ are good with C99 and C++ 2003.

I've been working on a design outline for a modern operating system since "why not", if it's of interest.

The, "generative programming", is a term from the 1960's.

The "AI-generated code" should basically need pass through a requirement of being understandable to a team of Indian software developers in Java only allowed to speak English.

Of course, one needs take care when using the word "only", for example in the usual talk of the day, since it can mean more or different than only "only".

Same goes for "need" in the negative, whether "we don't need that" is versus "we need not that".

The "since" and "until" are often among the most suprising or unintuitive keywords represented in language, since they're as of temporal modality, vis-a-vis "until" and "while".

Something like "unless", that's a quick first step. With a long way down, ....

"There is no 'but', only 'yet', in modal, temporal, relevance logic."

A computer scientist once noted: "programming is the art of naming things."

Not all programmers are analysts.

Yeah my O.S. design is basically to take advantage of the fact that the modern commodity architectures have left behind lots of assumptions of the single-core and about interrupts mostly then about the ubiquity of PCIe bus and the necessity of the efficient employment of DMA, then that many-core basically means that modern commodity general-purpose boards need be treated as models of self-contained distributed systems themselves, so, fundamentally "asynchronous", as this simplifies a lot of things, for models of co-operative multi-tasking, while acknowledging that user program are nominally adversarial, and the network is nominally un-trusted.

Serious hint to anyone thinking about a career in software: Make sure to develop a solid understanding of at least digital hardware. Build, experiment with micro controller eval boards (they are cheap), learn how to use a logic analyzer and an oscilloscope. That will hugely increase your job security or your self-employed income prospects.

I am still doing all my book-keeping on 30+ year old software, MS-Works. It still ... just works. Even on a Linux system (using WINE).

Jeff Liebermann snipped-for-privacy@cruzio.com wrote: |-----------------------------------------------------------------------| |"Never mind that the experts and the consensus are often wrong: | |