The most durable tech is boring, old, and everywhere COBOL turned 66 this year and is still in use today. Major retail and commercial banks continue to run core account processing, ATM networks, credit card clearing, and batch end-of-day settlement. On top of that, many payment networks, stock exchanges, and clearinghouses rely on COBOL for high‑volume, high‑reliability batch and …
> we all use Adobe PDF when we need a document to look and behave the same everywhere
Personally I assign that attribute to unadorned text (.txt) files.
On a more basic or BASIC level, I think there is still a lot of life in binary logic, RS232 comms and FORTRAN. On a more contentious level, what about good old tape in all its forms?
Isn't Fortran likely to be somewhat faster than Python? What with it being a compiled language. And it is still a procedural language (AFAIK) so a call is a call to a location in memory and doesn't need to be bound to the bit of the heap with the instance data before the code can execute.
> no one had the hardware to even run them anymore.
Do a bit of googling. Nowadays it's possible to "scan" cards (even a decent AI should be able to transcribe the code from a picture of the cards) and then the code can be run on any of a variety of emulators, some as simple to use as a web page with some JavaScript.
Like C, FORTRAN is for speed. Classic HPC models are still largely written in FORTRAN rather than C, because it is more suited to mathematical models than C. C is rather better as a system programming language.
It's all around call by value compared to call by reference, as was explained to me by a data scientist when I worked at an HPC site. The indirection implied in a pointer based languages slows down the very fastest code that HPC models need to get the maximum performance from their systems.
It is possible to write very fast C for mathematics, but you have to bend the language to work more like a language like FORTRAN.
> Classic HPC models are still largely written in FORTRAN rather than C, because it is more suited to mathematical models than C
That is not the case. Speaking from experience, "classic" models are in Fortran because they were originally written in that language and the code is such a mess that nobody has had the guts to rewrite it.
> It's all around call by value compared to call by reference, as was explained to me by a data scientist
Not by a computer scientist, clearly.
> The indirection implied in a pointer based languages
C uses call by value. Call by reference can be emulated via pointers.
> slows down the very fastest code
And copying (complex values) doesn't?
Ah. I see our mutual misunderstanding. Over the years, the meaning of "by reference" and "by value" seems to have changed.
When I say "by reference", I mean that a pointer to the actual data object is passed. When I say "by value", I mean that the actual value to be worked on is passed.
In 'classic' Fortran (I'm sure that more modern Fortran implementations have additional modes more like other languages), for the first several parameters, the value to be passed is actually loaded into registers, and the function is called. The values are immediately available to register operations by the CPU inside of the function (register to register operations are almost always faster than any memory reference on all architectures, even those using memory backed registers). If they are changed, it does not affect the copy in the memory location of the variable, even if the register is changed. Any return value has to be passed back in a register, one is normally allocated in the link convention for the architecture.
This is not a problem, the only issue is that the compiler has to be careful about tracking the use of registers before and after function calls. But this can be done at compile time and by convention. By reserving several registers used as part of the calling conventions, many data copy operations are avoided, including the putting the values on the stack and pulling them off. But this cannot handle anything other than single register data types (int, float and others depending on architecture), which is why, in my opinion, call by reference (passing a pointer) is more common nowadays.
My terminology use is archaic (the last actual performace tuning courses I did was over 35 years ago), so what I say may not actually match current use, as that appears to have changed over time. And as such, I may have mis-interpreted what I was told, but I don't think that I did.
It seems that as other more modern languages have come along, the actual meaning of 'by reference' and 'by value' has changed.
> It seems that as other more modern languages have come along, the actual meaning of 'by reference' and 'by value' has changed.
No it hasn't. It's exactly the same as it's always been and as you describe above.
Where I think you got it arse backwards is that Fortran is pass by reference by default (unless using VALUE) whereas C is pass by value by default (unless using pointers, or references in C++).
It does not make any real difference in performance unless the code is written by a particularly incompetent programmer that doesn't know when to use which method (e.g. unnecessarily passing structures by value in C will hurt performance, as will passing arguments by reference, the default, to recursive functions in Fortran).
Your data scientist may have taken 2+2 and gotten 5 as a result. Your CPU will use addresses and values regardless of what the higher-level language uses, C makes addresses visible to programmer while some languages don't. Whichever language you use, it will eventually be turned into machine code and that is what matters: how the idea expressed in languge is transformed.
Pointers are designed to avoid data copying such as when sorting data: you don't need data copies when you just shuffle around pointers, so that can make certain algorithms very fast.
The main reason why something like Fortran might be fast is because it has implementation of various algorithms that have been tuned over decades of use into most efficient they can be. Not due to "indirection" since in majority of cases the cost would negligble: there are many registers and large caches in CPUs these days, pre-fetch logic to access information and other ways to make them very fast.
See my reply to the first reply to my comment. Under many circumstances Fortran has traditionally avoided memory operations by passing parameters directly in registers.
Whilst I agree with you about the fact that most languages obscure the exact way that variables are processed, Fortran often coded variable references directly into the compiled code, reducing the need for indirection through pointers.
At times in the past 40+ years, I have written PDP-11, s370, Z80 and 6502 assembler, not that frequently, but enough that I am aware of how memory and addressing modes work, and as I am now working on IBM Power, I am also aware of just how many complex direct, indirect and multiple indirect addressing modes processors can have, even if they are judged to be RISC processors (the Power architecture has just so many instructions and addressing modes, IBM even tried to change the definition of RISC from "Reduced Instruction Set Computer" to "Reduced Instruction Set Cycle-time" - I probably still have some IBM promo material somewhere which tries to defines this!)
And I don't think my data scientist would have got it wrong, he was responsible for the technical oversight of the development of one of the main weather forecasting models used in the world, and frequently spoke at international conferences. If anybody got it wrong, it would have been me, and maybe I was mis-remembering exactly what I was told, but I don't think that I did. It's amazing who you get to work with when you are the onsite technical liason between an HPC customer and the HPC vendor!
I'm guessing you use one of a small number of languages that use the most simple character encoding available, because when I get plain text files written in something that doesn't use the Latin alphabet or even one that does but has plenty of diacritics, you get all sorts of fun character encoding games to play. Of course, you might have meant UTF-8 plain text files which is the closest thing to a standard, but you didn't say it and you still have to play the games sometimes when someone hasn't understood or checked that they did that correctly.
You presumably also don't have images, diagrams, meaningful formatting or layout, navigation, or the many other things that plain text doesn't provide. If you are using a text-based format like LaTeX or markdown, then you're not using plain text because you're dependent on all the software used to translate that to the form unfamiliar users will be using. As long as we limit ourselves to the two or three things that text can do, it's great, but don't be surprised that the rest of the world isn't following suit. PDF introduces lots of new problems, but it does fix some of text's.
You're right. Myself, I'm a big fan of plain ASCII text wherever possible. But for most of humanity, computers are tools, Nothing more. Most folks couldn't care less what the storage/transmission formats look like as long as the outputs are what they need. A lawyer once pointed out to me that legal professionals expect many of their documents to conform to established layout conventions. The same data in a different layout is harder for them to work with. For them PDF is a blessing because dates, content headers, amounts etc are where they are expected to be. I'm sure that something similar is true for many other kinds of users.
The use of PDF by most lawyers I've worked with has been absolutely minimal. They all seem to prefer emailing word documents backwards and forwards with change tracking switched on.
Realistically they would be able to work much effectively using text documents in Git. Unfortunately the legal profession went through the painful process of sacking all their their typists and learning to use a mouse just 30 years ago, and you can't expect them to change working processes more than once every 50 years.
Worse still, they take word processed documents (in whatever format, but fundamentally with ASCII-encoded characters), print them on a crappy inkjet printer and scan them at low resolution, so that even good OCR can't read them.
Then they send 40MB emails 20 mins before a court hearing and conveniently lose evidence that has been "served" on them so that the judge disallows it.
Court system is just as bad. They have "statements of truth" that of course don't make anything true and "certificates of service" that don't certify anything, because their IT systems don't provide meaningful receipts for "served" documents.
Do I need to go on?
We do public consultation software. One of our clients printed out letters to submitters, so the mayor could physically sign each one. They then scanned the letters (to PDF) and uploaded them back into our system to email to the submitters. They then wondered why the links in the PDFs wouldn't work anymore.
the legal profession went through the painful process of sacking all their their typists and learning to use a mouse just 30 years ago, and you can't expect them to change working processes more than once every 50 years.
That misunderstands what actually happened.
The secretaries always actually did most of the routine work on a legal file with complicated fiddly bits being dictated via audio dictation.
What happened with Legal Case Management Systems is that all of the secretaries became case handlers in their own right; termed paralegals. They then did about 15 times the amount of work as the Solicitors, who were increasingly relegated to only doing the complicated legal work that paralegals can't do.
Realistically they would be able to work much effectively using text documents in Git.
Realistically, git is outright primitive and considerably less efficient than the existing case management systems which combine a document management system with a templating system which creates an email with a word document created and attached requiring no editing, a calendar system which diarises chasing up documents and electronic document signing. Emailing things around is inefficient compared to uploading it directly to the CMS (which is possible via a web portal) but requiring people to use different web portals to interact with other companies would be a monumental pain in the ass and so email between firms is the standard.
But then again, all mainstream CMS's support having a process sitting there and scanning for emailed documents which have the appropriate references, and automatically filing them and scheduling the required follow up actions, which I don't think that Git supports either.
you can't expect them to change working processes more than once every 50 years.
You do realise that accepted working practices change more frequently and radically in law than in IT, right? There's a reason that the legal world has a training ecosystem that makes it IT training ecosystem look like a bad joke, and it's not because lawyers enjoy wasting money.
Unadorned txt files - Yep, no line breaks, at least one line between paragraphs and three lines for sections. Quotes are OK. IF you really need emphasis, 1, 2, or 3 asterisks delimiting the text (opening the file with a Markdown reader will give italics, bold, and emphasised) and the file will still be readable in plain text.
This one: commonmarkup.org/help - Gruber/Swartz standardized…
I believe that almost all of the derivatives follow the simple asterisk formatting that I posted, probably even those that expect the underscore delimiter for italic - the worst that will happen is that you will see the asterisks, which would still emphasise the delineated text as ’special’.
> I have to use 4 mutually incompatible variants at work
What are the incompatibilities that cause you grief?
Is it possible that Markdown is not the right choice for your scenario if you need to rely on its more esoteric features / extensions (and falling back to HTML is not an option)?
LTO (whatever number it's at now) and Exadata are pretty decent, but LTO is my no means backwards compatible, and all tape needs constant refresh.
The last time we used tape to migrate was 2011. Everything since has been by shipping an encrypted NAS box. VTL replaced tape for us during the same 2011 migration and saved a ton of support cost and pain, but even that is looking old hat now.
I offer nfs as a candidate.
That was a 'standard' for a real short time, and even in that time it changed.
2.3GB when first released. 5GB not that long after Mammoth 10GB (20GB compressed) a few years after that, and then it morphed into AIT, which although it used the same Video8 style tape cases, was mostly incompatible beyond the first generation.
And if you used a 2.3GB or 5GB tape in a Mammoth drive, you needed to clean the drive before you could use it again.
Not a good standard. LTO is not much better, as although the drive and tape format has remained relatively constant, you need to re-write your data at least every three generations of drive due to the head and tape technology moving on.
Comic Sans is OK. AriaI and the Iike are those which do not distinguish between capitaI l for lndia and Iower case I for Iima.
As a resuIt consider Al: is it short for ArtificiaI lntelIigence or the name AIlan? You have to copy and paste into something set to dispIay serif or a better sans serif font to teIl the difference.
GilI Sans throws in confusion with the number 1. l think at least one of the Johnson variants differentiates the Ietters but then confuses l for lndia with the number and some of them do differentiate. lt's an interesting exercise if you have muItiple fonts avaiIable to fire up your word processor, put the offending Ietters and numeraI together and see how many fonts give you three cIearIy differentiated gIyphs.
In defense of Comic Sans, it has its uses. It's what I reach for if I want something to look informal -- hand written but not like a wedding invitation. In such cases a script font like Zapf Chancery would be way over the top.
Comic Sans would be a good fit for a UI prototype, along with slightly wobbly lines that looked as though they'd been drawn freehand, as a visual cue that "this thing doesn't actually exist yet; it's just a mock-up."
A PDF file that looks the same everywhere?
Not quite; Try and print a PDF that originates from the US in the civilised world any you’ll get one of two things: “PC Load Letter”, or a document that proportionally slightly smaller than the original.
I think Adobe saw “PC load letter” as bad marketing (there IS such a thing as bad marketing) and therefore made Acrobat automatically shrink letter sized documents to A4. Similar, but not the same.
Remember printing Slackware howto documents before the turn of the century, and almost without fail, the page was formatted beautifully for letter paper. Which meant I had twice as many pages, but with a single, or at most two lines on the second page. Details are foggy at this point but I remember thinking that the author had done a great job of formatting the documents for a very specific paper size.
Take away from all this? Not sure, but in IT, Standards are the things that divide us.
I kind of get the benefit of that relationship to paper manufacturers, and sure, it's kind of elegant as a standard, but why does it matter to an end user?
If I want to gang up two copies of a thing on 8.5" x 11" paper which I then (have the printing house) cut in half, I can do that. What's the disadvantage that my 5.5" x 8.5" end product is a non-standard size?
(If I were used to A4 and friends, maybe the answer would be obvious, but as a left-pondian I'm not, so it isn't. Guess I need it explained like I'm 5, please and thank you.)
This is a reasonable, short piece on the problem
https://www.ezeep.com/why-the-difference-between-a4-and-letter-actually-matters/
Basically, the ISO 216 series of paper sizes (the official grouping which includes A4) was designed with the user in mind, US paper sizes were not designed and so frustrate attempts to work across the range of scales/sheet sizes.
I don't think RS232 in it's full glory will persist. what will persist is three wire serial comms which is the minimal bidirectional subset of RS232.
So, RX, TX and SG, at power of two multiples of 300 bits per second, with 8 bit bytes, working at +-3.5-15V (although modern implementations often run at +-3.5-5V or even TTL 0-5V), probably simple one bit parity (but which may be disabled) and one stop bit for synchronisation. That's more like bidirectional 3 wire serial telegraphy, not RS232.
Full RS232 has hardware flow control and barious device readiness lines, and even has a synchronous clocked mode. Most of the 25 pins in a DB25 connector are assigned to one thing or another. You will not see any of these on modern serial implementations.
I've recently been wiring up both the serial UART in my PiDP-11, and also USB to so-called RS232 adapters, and these are both only 3-wire connections. But then so is the UART serial port on the pic32mx and Raspberry Pi PICO micro controllers in the hardware serial terminals I've also built (from kits, I have to say).
I suspect that "RS232 in it's full glory" has already died out. But as you say, the three-wire minimum subset [1] is still going, if not strongly, and the small renaissance it's seen courtesy of Pi's etc., suggests that'll be with us for some time to come.
Given the amazing breadth of experience among Reg commentards collectively, I imagine that, for every pin on a DB-25 connector [2], there'll be someone here who can say, "I've worked with a device that used that pin." But: (a) how many of said devices were made after, say, the mid-80s?, and (b) how many of them are still in service?
Though I've been dealing with RS-232 since 1980 or thereabouts, I personally have never seen a device that used pins other than (1-8, 20, 22) -- but then my experience, though long, is rather limited in breadth. I spent most of my career in business computing; ASCII terminals and the occasional pen plotter are all I dealt with.
I've just in the last couple of months encountered my first *synchronous* RS-232 interface, in a very obscure synthesizer from the 70s. Haven't worked with it yet, but am excited to have the chance in the next few weeks, trying to get that connection working again.
[1] Strictly speaking, the minimum is two wires, if you only need one-way communication, e.g. some sensor that only transmits.
[2] Including the three that are "reserved" or "unimplemented". I suspect those have all seen non-standard usage at some point.
Text files that contain ASCII are not guaranteed to look the same everywhere.
Many viewers display spaces differently and some viewers display tabs as 4 spaces and some others display tabs as 8 spaces.
While most text viewers at least support \n newlines, some text viewers only support \r\n and some even \r.
Vertical tab, horizontal tab, form feed, backspace and bell are all ASCII characters that are not decorations and that also render completely differently depending on editor.
Very few editors support a font that shows the file separator, group separator, record separator or unit separator characters correctly.
For example; is the Unit Separator, but in most browsers it is rendered as 0x001F in a box.
Meanwhile, a pdf that is to the specification and is not full of JavaScript is far more likely to render how you would expect.
GNU fortran is still having changes made.
Most serial protocols over RS-232 use \r\n newlines, but it seems not all.
There are many different incompatible tape sizes, type and encoding formats (see LTO).
Reminded me that supposedly durable networking technologies (thinking here asynchronous transfer mode) can be rather ephemeral.
My punt is that TCP/IP will still be alive and kicking† in some form in 2126—that is if we aren't back to banging rocks together and catching on to this newfangled fire thing.
† presumably arse.
IPv4 will happily persist for as long as we want to connect together devices* restricted to a LAN and where we care about reducing the cost of the BOM - or otherwise just want to keep things simple. Ditto all the unencrypted versions of protocols running atop TCP/IP.
Well, at least in my household: those temperature probes in the compost aren't ever going to be given IPv6 addresses and - well, I guess one day I'll have to have a server tunnel the gloriously trivial HTTP and "call that HTML, it looks like pain text to me" WebUI because the damn browsers all refuse non-HTTPS connections even locally.
* trying very hard not to use "things" here.
Escape to the Country 2125 will likely be an underground documentary about a ragged group of survivors hiding from our AI zombie overlords. It will be full of technology which still runs PC-DOS 6.22, as this age of tech is the only type which can be trusted not to rise up and kill us.
Mainframes and COBOL arguably could still have a role, but it would have to be friendly 90s mainframes - the linked article about IBM's newest mainframes just had some sinister-looking boxes which threaten to do inferencing.
ASCII itself is in fact nothing else than an extended Baudot code
I don't see any similarity between Baudot code and ASCII
> I don't see any similarity between Baudot code and ASCII
You do not see any similarity between a fixed length binary code and a fixed length binary code?
Baudot's invention was a great advancement over American painter Samuel Morse's well known code as it meant that Hughes' printing telegraph could be not only greatly simplified but, most importantly, automated.
ASCII's lineage traces back to Baudot through ITA-2, a 5-bit standardisation of Baudot code for international use.
You do not see any similarity between a fixed length binary code and a fixed length binary code?
In that case it goes back to Jean-Marie Jacquard in 1801 or who knows? maybe Archimedes.
The article is about digital formats, not physical ones. Baudot's code was five bits, with some versions designed to use fewer holes for the most common letters (cf Morse code, but also cf absolutely not qwerty), whereas ASCII goes sequentially through the alphabet.
The connection between EBCDIC and Hollerith cards is rather more obvious.
Then I suppose we might investigate the history of the alphabet and its order.
ASCII is an extension of Baudot only because they're both fixed-length binary? That seems like a very broad category to use to construct an X extends from Y relationship from. But if you're going to argue for that, say hello to Braille, the 6-bit binary code that predates Baudot by decades. Of course, its representation of letters is entirely unrelated to that of either Baudot or ASCII, but fixed-length binary means poor Baudot is going to have to lose the original credit using your own logic, and since Baudot code originally also used six bits and involved punching holes in paper, there are two other reasons that are as valid as that one (not very much).
> ASCII is an extension of Baudot only because they're both fixed-length binary?
ASCII derives from Baudot (via ITA-2) as an explicit evolution, not as independent invention.
The idea of a fixed length binary code may seem obvious and trivial to a person familiar with computers in the 21st century. That wasn't so in the 19th century.
I think the major improvement of ASCII over previous encoding methods including Baudot was sorting characters in their natural order instead of them being randomly scattered across the code space. This, incidently, is what made learning Morse so hard for me, there's no structure to the encoding.
> sorting characters in their natural order instead of them being randomly scattered across the code space
That was only feasible once the technology reached a certain level of maturity. I cannot recall the specifics of the ordering in Baudot code but there was a logic to it (I think it was ergonomics but don't quote me on this).
As for Morse, the general idea was/is that the code length was inversely proportional to the letter's frequency of use (according to someone) in English.
Best way to learn is, like everything, frequent purposeful practice. I find that listening is much more effective than looking at the dits and days. I used to pretend that I was listening to someone speaking with a particularly thick accent.
Quite right about Morse and it's choice of mapping code (technically, cipher) points to letters according to frequency. AKA Huffman coding. Plain text English Morse sequences are self-compressing, how about that?
> say hello to Braille, the 6-bit binary code that predates Baudot by decades
I did not mention the system developed by Louis Braille (a fellow Frenchman) because while its structure can be analysed as a fixed length binary code, it:
1. Was not conceived as such, that was merely an artefact of simplifying previous tactile systems.
2. There is no link between it and Baudot or ASCII, it is merely a spurious correlation, if you will.
A better, non spurious, example would have been the Jacquard (Joseph Marie) loom, which used punched cards, but as in point 2 above, there is no intrinsic link between that and Baudot,¹ so it would be preposterous to claim that ASCII goes back to it.
¹ One being a character encoding system for machine to machine data transfer, the other being a data input system and human machine interface.
"while its [Braille's] structure can be analysed as a fixed length binary code, it: 1. Was not conceived as such, that was merely an artefact of simplifying previous tactile systems."
Rubbish. Braille is a 6-bit code by design. It has been so since the beginning. Every character was defined as a single pattern of six dots, up or down. A is and always has been ⠁⠀(100000), and Z is and always has been ⠵⠀(101011). The quantity and order of bits have been unchanged. That's fixed length under any plausible definition.
"There is no link between it and Baudot or ASCII, it is merely a spurious correlation, if you will."
On that however, you are very correct. As are those who have correctly pointed out that being fixed in length is not enough to link Baudot and ASCII when their correlation also has no relationship to one another. Braille, Baudot, and ASCII all have fixed-length sequences representing characters for communication. If that is not enough, then it is not enough for Baudot and ASCII either. All the Baudot -> ITA-* -> ASCII sequence demonstrates is that these were all character codes used in telegraphs, but being used for the same purpose is not enough to demonstrate that they extended from one another.
> being used for the same purpose is not enough to demonstrate that they extended from one another
They *are* evolutions of one another, with Baudot as the root of the tree (I did the research years ago for a paper I wrote on the subject).¹
> Braille is a 6-bit code by design
I'm sorry but that is not the case. I do have a copy of Braille's book in front of me (interestingly, accessibility was already a thing back then) and an electronic copy may be found here: https://archive.org/details/procdpourcrirele00loui/ The book describing the system upon which Louis Braille based his can be found here: https://books.google.fr/books?id=lkVzrUr1RvEC Both describe their methods in terms of a tactile matrix of rows and columns which is interpreted in terms of its spatial representation. As already pointed out above, the fact that it can be analysed as a fixed length binary encoding is a mere coincidence not a design feature.
¹ Not my paper, but one that covers similar ground in the subject at hand: https://ia601805.us.archive.org/24/items/enf-ascii/ascii.pdf
ATM belongs to the fixed frame, synchronous, type of network format used by Telcos. Its a way of putting data onto voice oriented protocols but as we now use voice over data oriented protocols its somewhat redundant. (IMHO) Just bear in mind that anything telco related tends to change very slowly.
As for TCP/IP I've always regarded TCP as a bit of a lash up, its a good choice to send what would normally be RS232 serial data from a terminal to a timeshare computer. Unfortunately its got used for lots of other things, the most common use being ironic because the first thing the protocol on top of the 'stream' protocol does is try to introduce framing again. (So, realistically, the sooner TCP dies the death the better. I can live with IPv4, its got limitations, but TCP is not reliable in the form its most commonly used in and is a traffic hog.)
PDF and DOC/X are editable by open source software and will survive the collapse of their parent companies.
There are very few technology companies that will survive 50 or 100 years: at the moment I can only think of a couple. (IBM is a shade over 100; Ericsson will be 150 years old in 2026.)
Open standards (and open source) is the secret of longevity.
PDF and DOC/X are editable by open source software and will survive the collapse of their parent companies.
Not necessarily very well though, due to the many ways of interpreting the so-called "standard". I find PDFs created from Word documents can be particularly troublesome.
Trying to print the GCHQ Christmas quiz this year, Libre Office Draw could only import the first page*, Okular printed it out with some text missing and some incorrect colours (though on-screen display was fine) and Inkscape couldn't deal with the embedded fonts.
The best non-Adobe reader/editor I've used is Xara, though I gather Serif has a good bash too. Both are paid-for products.
M.
*The three variations are simply in "cover design". The core quiz is the same on all three so it's not strictly necessary to print them all out.
Thanks for this pointer ... there is even a [very] beta version on Android, iOS etc !!!
Worth a punt, so to speak.
I use an old copy of 'Foxit PhantomPDF' on Windoze to edit and manipulate .pdf files, never had a problem with any .pdf file BUT know that .pdf files from 'interesting' sources can be 'challenging' to manipulate/print.
Usually this is because someone has not understood the PDF Standard(s) (!!!???) and created a 'frankenpdf' ... sometimes converting to an old version of the standard can purge the 'borken' bits in the .pdf file ... BUT more usually it makes the 'frankenpdf' more 'interesting' :=)
P.S.
For maximum 'fun' try MS word <==> .pdf <==> MS word as a conversion path.
You will discover what 'words', 'fonts & formats' and 'visual layout' are REALLY considered necessary by 'MS word'/'PDF standard' du jour !!!
:)
When looking at some credit card statements on my Linux machine, evince/poppler had some text missing. (Hard to know when the text just isn't there, but the clue here was mostly-blank pages.) Turns out that the imbedded font had a syntax error, apparently for ALL the statements from that company. So 2 issues: 1) CC co's PDF software had a mistake, and 2) evince/poppler simply wouldn't render anything with a font problem. Reported to both CC co and poppler in 2021; CC co never responded, and poppler bug status is not fixed and not assigned.
Be strict in your output, but permissive and forgiving with your input!
The ISO specification is available at no cost here: pdfa.org - ISO 3200-2. Personally, I have found it best avoid Adobe software.
> Siemens started out sometime in the 1850s.
And had some decent labour conditions for a while. Come the 1930s and they went along with it, eventually going for the whole slavery thing during what was Germany's (roughly) 12th war of aggression in the 20th century. After that, they expanded internationally in the same way as other German companies: through bribery and corruption (bribes were tax deductible in Germany until 1999 or so, so long as you were bribing foreigners… don't shit on your own lawn and all that).
Prove my imaginary friend doesn't exist!
No!
Then we will continue trying to expand.
Same for all major religions - with some still espousing the need to procreate 6+ children to be a good follower, when our population is already too large for our planet.
Even China (without official religion) is trying to increase their birth rate.
We're a' doomed, ah tell ye, doomed!
> Prove my imaginary friend doesn't exist!
Why do you feel the need to be an arse?
Personally, I am an atheist, but whether a person believes in a supreme being or not is purely a matter of faith and therefore strictly personal. Faith is orthogonal to science, thus one does not "prove" or "disprove" in any useful sense.
Criticising someone else's faith, or lack thereof, is a sign of insecurity.
As for religion, it's such a vague term… as used in practice it can mean anything from "code of law" to "philosophical system" to "articles of incorporation" to "README.txt" Still, as any social convention it proves useful to some.
Lastly, I guarantee you haven't seen your life flash before your eyes (it's a real thing, btw). During a tricky situation in my younger days, my very competent and resourceful colleague was asked "what do we do now, sarge?" His answer, allegedly, was "You're the fucking believer. Start praying!"
Rubbish. The only thing more robust than your sanctimony is your confidence that it counts as wisdom.
“Faith is strictly personal,” you say - which is a fascinating defence for a worldview that has historically involved door-knocking campaigns, compulsory schooling, compulsory worship, compulsory morality, compulsory taxes, and the occasional compulsory burning. Nothing screams strictly personal like a cathedral, an inquisition, and a voting bloc.
Faith isn’t “orthogonal to science.” It’s orthogonal to evidence. Which is not a coordinate system so much as a polite way of saying “immune to correction.” Children also operate on that model. They just have better excuses. Kids believe in Father Christmas. Adults believe in invisible sky executives who require weekly meetings, cash donations, and opinions about everyone else’s sex life. The only real difference is branding. Ironically, the bible gives the best advice here: “When I became a man, I put away childish things.”
Religion is not “a vague term.” It has a definition. A very ordinary, very boring, very dictionary-shaped definition. It does not mean “code of law,” “articles of incorporation,” or - and I’m still checking - “README.txt.” If your README file starts demanding worship and threatening eternal punishment, that’s not documentation, that’s malware.
And then there’s this: “I guarantee you haven’t seen your life flash before your eyes.”
I was clinically dead for six minutes on my living room floor.
Six.
Minutes.
That’s not a metaphor, a parable, or a vibes-based anecdote. That’s a medical timer. So perhaps before issuing guarantees about other people’s experiences, the sanctimony could be gently lowered from ivory tower to something more desk-lamp height. There's a good chap.
That's right, attack me not the argument. The rhetorical equivalent of missing the target and congratulating yourself on the noise.
No one here is “proselytising.” I’m not knocking on doors, handing out pamphlets, or threatening anyone with post-mortem real estate decisions. If that feels like an “attack,” that says more about the armour than the arrow.
As for “Dios los cría”… charming. But equivalence only works when the things being equated actually share properties. One side asserts invisible cosmic authorities and legislates from them. The other side says “prove it.” These are not mirror images. One is a claim, the other is a filter.
And yes -- the sanctimonious arse is, in fact, sanctimonious. That isn’t insecurity. That’s taxonomy. How is the ivory tower, by the way? Still got a good view of everyone else’s supposed moral failings from up there? Gravity works down here. And it’s wonderfully non-metaphorical.
"In other words: common ownership of the means of production (whether physical or intellectual) actually works."
Steady on chap that's practically COMMUNISM ! Joking aside, while I do advocate in putting community before profit, I really do mean that this is about ensuring that a person or organization does not hold a *monopoly* on a form of communication (in the form of source code).
> Steady on chap that's practically COMMUNISM ! Joking aside
That's not "practically" communism but a fundamental principle of it, and I am not joking.
The US population need to get over the negative image of Marxist thinking imposed in the late 19th and especially early 20th century by Rockefeller, Carnegie, Ford, et al. as they sought to protect their own interests.
One does not need to be a full on anti capitalist, but FOSS demonstrates that common ownership of the means of production can behave as predicted by Dr Marx. On a related note, that the US government sees value in socialism was already shown in 2008 when the taxpayer rescued the US financial system. :)
"musicians have discovered there's no easy way to port Finale compositions to any other format"
Following the link reveals two points. 1. There's no hint of an apology to their customers, just thanks for contributing money over the years and 2. files can be exported to an open standard MusicXML.
After one year, beginning August 2025, these changes will go into effect:
It will not be possible to authorize Finale on any new devices, or reauthorize Finale
Modern software in a nutshell - you paid for it but we still own it, and when we can't work out what to do with it next we will screw you.
They don't want to sell or maintain it any more, but one final update which disables the activation check and leaves you with the software you paid for is still out of the question.
Hmmm ... seems like you have to go through a [proprietary] "Dorico Pro crossgrade" so that you can "export your [proprietary] Finale files using MusicXML 4.0" and then import those in [proprietary] Overture ... not a truly FOSS solution (though MusicXML is an Open Format). Plus, the software doesn't run on Linux afaics ... ;(
Maybe the GNU's LilyPond, written in C++ and extensible via Scheme/GUILE (does it have a GUI?), or MuseScore et al. could lessen entrapment here ... ?
Some composers still use Acorn Sibelius, along with the hardware to run it on (the copy protection being resistant to emulators). Modern Sibelius (owned by Avid, like Finale) seems to be EOL in all but name, but since even older versions still run on Windows 10, it's hanging on.
For my own occasional uses, I've found MuseScore to be pretty decent for some years now (I gave it a fairly thorough try for 20th century art song in about 2017), and as a software developer, I too cannot get my head around Lilypond's text-based notation—tried it in 2003, and after that stuck with Sibelius until MuseScore came along. Fair play to those who can grok it though; in particular those of us who work in church music owe a lovely libre edition of music of Tomás Luis de Victoria's œuvre to a dedicated musicologist using Lilypond.
MusicXML is pretty good. I followed the development for years. If the export/import works ok users will simply need to buy and learn the new app. We do this all the time with appliances, cars, etc.
The article seems to imply that open source is better than proprietary code, however, compensation is sketchy, the code can be deliberately munged, and the constant update/churn forces constant attention and testing. The same can happen with proprietary code. The problem is that software overall seems to be more random. Pressing a button, control, link, etc. does not always do what it did or does in another app or version and could even lead to harmful consequences. Ai won't fix this and may make it worse. While Ai can completely rewrite a UI on the fly, users need to figure out what went were and may end up completely lost and unable to do their work. This is a disturbing trend with no end in sight.
MakeMusic points to a way forward with a different product. Having migrated code and dealing continually with updates to tools and apps as a developer, I feel this is better than nothing. It may seem like they have "taken the money and run," but on the other hand, continuing a product that costs more to maintain than the revenue it creates is unsustainable. The product or license is sold "as is" but with the platforms underneath under constant revision, the obsolesce and maintenance costs can escalate and are to be expected.
Cavet Emptor.
"continuing a product that costs more to maintain than the revenue it creates is unsustainable"
This is true, but this seems to have been done in a dog in a manger way. There are better alternatives.
There could, as another commentard has said, have been a final update that remove checking. That would have cost very little effort and given those who've paid over the years something permanent for their money. AIUI if they need to replace hardware - which they will at some point in time - they can't take it with them.
Source could have been placed in the public domain.
At the very least there could have been an apology to customers who have been dumped.
It is the usual "if it uses the cloud it's not yours" discussion.
Three years ago a friend bought some "cloud-powered" home automation contraption or another. £400 or so, not cheap, and it was utter crap (made in Germany so no surprise there). Anyway, he was trying to figure out how to get it to work and I told him "don't bother. In two years time they'll discontinue it, pull the plug on the server, and you'll have a £400 brick".
A year ago I was visiting and he tells me "remember that contraption I bought? They just discontinued it and pulled the plug on the server".
Fool me once…
The security problem with C is developer culture. Many compilers, such as gcc and llvm, support runtime checking, such as array/pointer bounds. However, the developer culture of C is not to use these compiler options, which default to off.
The culture of Rust is that runtime checking is on by default. It has always struck me as crazy that a change of language is needed to get developers to switch from a culture of runtime checking off to a culture of runtime checking on. On the other hand, rewriting code is more fun than maintaining existing code, and they have the fun of learning a new language.
What young developer want to use the language that their parents use? Rust is just so much more trendier than C. I am predicting that Zig will replace Rust as the Trendy language: https://shape-of-code.com/2025/02/16/zig-is-the-next-fashionable-language/
For Fortran the folklore is a 1 to 3 times slowdown depending on the code, but I haven't measured it in a decade or so. And, given the right flags, the code aborts and gives a traceback. Which is nice.
But comparisons are hard. For example if a language has a "for I in a collection" type construct and the collection can't change a clever compiler can skip some of the checking. C and Fortran lack this, but in Julia and (I think) Rust it is the normal looping method, maybe a reflection of the increased awareness of safety since god's own language and C were devised.
Rust largely provides security guarantees through compile-time checking and forcing developers to design structures in a way which allows the compile-time checks to happen. This prevents stale pointers and the whole class of issues they cause with a runtime cost of essentially zero.
Things like array bounds checking are in there at runtime, but aren't especially expensive, and probably can't be avoided in secure code whatever the language used. In terms of how these are handled, it's entirely up to the developer whether they want to write code which handles out-of-bounds conditions or not. The security guarantee is that an unhandled out-of-bounds condition will lead to the process panicking and terminating, rather than sharing the contents of unallocated memory with unfriendly people on the internet.
As far as I can tell, reading uninitialized memory is regarded as memory safe if done a certain way and thus Rust therefore Rust wouldn't have prevented heartbleed, other than making the developers give up on implementing TLS heartbeats.
It seems a lot of Rust will "helpfully" panic() when an out-of-bounds condition is detected, instead of correctly having the function stop and return an error.
C (and C++) do have something Rust does not: Formal specifications of the language codified as ISO standards. By contrast Rust presents a (slow) moving informally defined target for it's community, rolling out a formal spec of the language & it's libs every few years would give the community a much stronger foundation to use and develop the ecosystem around Rust. This doesn't have to stop the language from developing - standards certainly have not put the brakes on C++. As it stands I don't think there's much to stop Rust from being captured by a litigious corporation (eg: Oracle & Java) and run into the ground with lawsuits and apathy - standards would help insulate Rust from the worst effects of that outcome.
Yes, excellent point, and add Fortran to the list. Even if it doesn't go over to the dark side standardization of a language encourages multiple implementations, and multiple implementations is both an extremely useful debugging tool and a good way to increase the effective bus factor of a project, so improving sustainability. It's one of the reasons while I'll play with Julia and Rust, but have no intention to use them for anything serious.
The MIDI Association have been pushing a new MIDI 2.0 specification for a few years.
However you cannot get hold of the core specification without paying at least $240, while MIDI 1.x is free.
Unlike (eg) PDF and DMX, MIDI 1.x and 2.x are also specifications, not standards. Among other things, this means midi.org is the only place anyone can legally get it - ANSI, BSI, ISO etc members can't access it.
that cost for a printed copy of the formal spec was true about 5 years ago but now everything is on midi.org for free, including midi 2.0 specs. only a sysex id you need to pay for. no one has been ever held back to develop code or products by this because many books document the 1.0 spec.
There's new things and new things.
US-ASCII isn't capable of transferring anything other than US English text without data loss. Not even English - no £ sign for example. Codepages kind of worked for at least European written languages, but caused worse problems.
So Unicode is necessary, despite the mouse vote not being recorded. UTF-16 seemed fine at first, except that 65535 codepoints also turns out to be wildly insufficient for the breadth of human written language, so variable-length characters and combining glyphs are needed.
Thus UTF-8 is the objectively better text encoding, despite being much newer.
One of the most amazing things that I feel fortunate to have witnessed in my years was the mating of the old and new in the late 70’s where typesetters were using modern (8 bit) computers to compose type and send a digital signal to the appropriate Linotype for output.
The Star Readers which produced a punched paper tape that had to be manually inserted into a reader which would then activate solenoids on the appropriate keys of the Linotype to drop the mats, were being phased out. The individual computer terminals which the typesetters used, were networked to a mainframe that would sort the individual orders and had its output devices as a bank of 8 Linotypes.
To watch the keyboards of all 8 Linotypes whos keys were all moving as if some phantom typesetter was sitting in front of them was a real sight to see for me. I gained big respect for the Linotype Machinists who had to deal with front squirts and back squirts and cleaning mats and hanging pigs each shift.
https://fineartamerica.com/featured/linotype-operators-library-of-congressscience-photo-library.html
That sounds like the Mackenzie Printery & Newspaper Museum, which also has a collection of old presses, a Linotype, etc, much of the equipment in working condition.
It's in Queenston, Ontario, Canada, not far from Niagara Falls.
If El Reg ever decides to do a Geeks' Guide to not-Britain, this place should be on the list.
When I was there in Aug(?) 2012, the most modern of their vintage presses was busy cranking out brochures for the then-upcoming anniversary/reenactment of the Battle of Queenston Heights just up the hill. (Most of you won't have heard of that, but it looms large in early Canadian history.)
When I first joined my present employer (I got five years off for good behaviour), it was a Cambridge startup but had already been going more than a decade. It's still in active development, but now some of the current code is older than some of the people developing it (one person found a commit made on the day they were born).
>POSIX is from 1988.
>It predates all current operating systems
False - GNU from 1983-4 predates POSIX.
Linux is not a POSIX-compliant kernel *at all* (many of its SYSCALLs share the name of library functions defined in POSIX and do similar things, but such SYSCALLs are not POSIX).
windows is no longer POSIX-compliant *at all*.
GNU is not POSIX-compliant, although there is the option of setting POSIXLY_CORRECT=1 to get POSIX braindead behavior, like 512 byte blocks in df and df and also environ, bash, file, find, grep, more, patch, ps, renice and more.
GNU mostly does its own thing, but if POSIX has a good idea, GNU implements it, while ignoring the bad parts of POSIX - although POSIX at times have included ideas from GNU.
Only macOS was certified to be POSIX-compliant, as a previous version did pass the extremely proprietary POSIX suite.
Btw, it was Richard Stallman who suggested the name - IEEE seriously wanted to call the standard IEEE-IX.
I think I may go back to supporting Cobol / DB2 / CICS / IMS in my spare time. I have noticed an uptick in the number of jobs being advertised for on soil jobs in the UK. Maybe the penny has finally dropped that buying in cheap labour from other countries isn't the only way to do things.
It's derided because it isn't very exciting. But then it's almost rock solid which is exactly what you need for any accounting system. No issues with memory leaks or weird compiler issues, fixed format data structures and definition before things are compiled. You can see what it actually compiles into on an IBM Mainframe so that makes debugging (with the associated debug dump) a hell of a lot simpler than anything else I have ever used. Add in DB2 and you have a very effective way to build a system.
Grace Hopper knew what she was doing. You wont be building anything exciting with it, but what you will build will work day in day out until the 31st of December 9999.
"fixed format data structures"
A long while ago we had an accounts system which I'm pretty sure was written in COBOL although it was proprietary. It used C-ISAM as did the older versions of Informix and it would have been convenient to use it as look-up tables. On investigation it turned out that although there was a single data file it had multiple format records. The main "fixed" thing was the record length although I think there must have been some format indicator as well. AFAICR we CREATEed a table with the columns corresponding to the record type we wanted, deleted the files that that wrote and sym-linked in the data and index files from the accounts and accessed them with the WHERE clause picking out the appropriate records with whatever identified that format. In fact we might have repeated that for multiple format types.
factory or other industrial site using computers...
One set of controls speaks a language designed around 1985-86 the others speak ISO standard which is even older.
But I'll give them something, if I take a program from back in the dawn of time, and stick it in our all singing all dancing newest machine with its touchscreen and multiple help screens, then it will work.
PS it was only in the past few years we gave up using RS 232 ports to transmit the data, partly because they were old tech, but mostly because it took forever to transmit because the CAM system generates programs 6 megabytes in length....
Anyway
Icon >>> for happy new year
Indeed. My first job with a machine room had serial terminals with various VT100, and the ones which came after had networked serial terminal servers for console access.
Sure, IPMI/BMC gadgetry is fine, but I've installed and/or rescued many servers from a serial console. Still do, really -- even my home lab still does it that way to some extent.
Oh sure lets wake Boris' PTSD from dealing with the RS-232 problems that occur in an industrial setting.... from ground loops to loss of signal and everything inbetween (usually caused by 50 meter+ cable runs and idiots pulling the cable to remove said D-plug from the socket....)
I'm going for a hug with Mrs Roach now until I feel better
Most industrial systems I've encountered, at least the ones designed to send data long distances, used RS485 which is a lot more robust than RS232. Also, very easily converted these days (essentially just level shifting, in some ways analogous to the DI boxes (just an example) I am more familiar with, coming from an audio background) and transparent to the UARTs.
M.
I got used to it when serial consoles switched from 25-pin hoods (e.g. old Sun kit and HP-no-bloody-E minis) to 9-pin (PCs and later Unix workstations and such), so it wasn't that much more of a struggle when things (usually, yes, Cisco gear) showed up with RJ45 consoles.
Somewhere along the way, bright sparks at some of the terminal server vendors back then (Lantronix? Digi? Avocent?) worked out to pin their own ports to the same / compatible pinout as the telco devices and servers, so you didn't even need a hood or a dongle or custom cable for those -- just a regular ole cat5 cable you had in the machine room.
For us it was a big win over e.g. Annex III and IV gadgets with their big ole bulky centronix cables and a break-out cap on the end for 6 (?) rj45, or the clunky Portmasters and their own db25 ports, in some ways.
> Much as developers like to make fun of it
I haven't seen developers name fun of it. It's useful, it's efficient, it's popular, and it's developed in a fairly consistent direction.
People who want to sound like smartarses might occasionally diss it, but hey, if it makes them feel better about themselves so be it.
I just wish Eich could have got away with his original intention of embedding a Scheme (as others had done before, AutoCAD being perhaps the most famous example) but alas, marketing said no and that was not to be. Still, I find there is something Lispy about JavaScript. It's great to be able to use techniques such as higher order functions , lambdas, prototypes (a much more powerful paradigm than OOP), and closures without having to jump through hoops. Yes, it's missing continuations and proper TCO in practice, but I'm happy with what I can get.
I do recall I found a quirky thing in C back then. Something with structs. I can't remember exactly but some name clash thing. Like a member could not be named the same between two structs or something like that. I'd hit it occasionally and think it was a bug in the compiler. Long since fixed. I do remember the first time as a newbie programmer encountering the argc/argv main processing loop for arguments options. It took me quite some time to "get" what they were doing with the loop/switch statements. It was very clever to me back then. I also had mainly used fortran and was pretty surprised how difficult it was to do "math" in C. I mean you needed to include a specific file (math.h) to use the basics line sin/cos. It was clear C was about text not formulas like fortran. Eventually C became what I thought in and define problems in. I'll even use C sometimes where I am pretty sure others would use a shell script. After 50 years, its like walking.
For my part, the spring chicken that I am, I remember the early days of C++, when it was still a credible language and not just an excuse for people to go on a committee, for brownie points and to skive from work.
I had (still have, somewhere) Stroustrup's 1st edition and was using it both to teach myself the language and as a reference… except that probably about half the concepts presented in the book not been implemented in any known compiler and certainly not mine (Borland), which made the task rather frustrating.
"After 50 years, its like walking."
That's how I feel about vi and perl -- well, not quite so many years, but same idea.
Which is why vim remains my daily-driver editor, and perl is what I instinctively reach for when a shell script won't quite do the trick.
Both are pretty horrible usability-wise -- Liam Proven recently referred to "Stockholm Syndrome" re. vim and I don't disagree -- so I wouldn't dream of recommending either to someone who didn't already know it, but I've already paid the price, so...
Re-writing old file formats, byte by byte, into new (currently readable) formats could be a job for some sort of AI. Or maybe AI takes a larger role making the file format something that only it needs to 'worry' about while the human just performs desired functions on data via an HMI without any visibility or direct control over 'files'.
Maybe 20 or so years from now, some Gen B person entering (what remains of) the workforce overhears a couple of old Millenials talking about file formats and says, "What's a file format?".
I always got the sense that there were no 'files' or 'formats' to worry about in Star Trek (although The Orville came pretty close).
Anonymous because I mentioned AI in a non-AI article. Sorry.
Maybe 20 or so years from now, some Gen B person entering (what remains of) the workforce overhears a couple of old Millenials talking about file formats and says, "What's a file format?".
We're getting there. I had to explain to a colleague why iso-8859-1 wasn't like utf-8.
As I understand it, that's the general direction in which things are going. The driving forces behind AI (which, like it or not, have much more insight than any of us here) consider that programming languages and data structures will be obsolete at some point in the future.
Given that, at the end of the day, those can be viewed as mere tools to transform requirements into a working implementation, I see the sense of it.
If my illegitimate children come knocking on the door, my advice to them will be to become requirements analysts rather than programmers. That job will probably survive a generation or two longer than the alternative.
I always got the sense that there were no 'files' or 'formats' to worry about in Star Trek (although The Orville came pretty close).
I think you are mistaken there no.2 They still use files in the ships computer and refer to them as such.
There are quite a few references to files when querying the ships computer even back to Khan mentioning files. Here's Wesley Crusher requesting files.
YARN | Computer, call up the files on... What was his name? | Star Trek: The Next Generation (1987) - S03E12 The High Ground | Video clips by quotes | 375b1667 | 紗
https://share.google/QmuyVIiXe9B35wIPa
There's always going to be a nit picker. Next you'll be telling me how impossible warp speed really is, as if everybody else didn't already figure that out: "Actually, I think you'll find ...".
And I said "to worry about" not that they didn't exist somewhere in the system - the AI would manage (and hide) files and formats reducing complexity for the human user. It's not that far-fetched.
ST characters talked about files in the sense of folders (collections of data) not a document file or format per se. You should look past the use of language tailored for an audience (at the risk of being pedantic, the audience has to understand what the character is trying to do using terms the audience can quickly grasp or at least accept within the context of the storyline). Displays of data didn't look like files as we understand them. Data retrieval and display "just worked": "Computer, calculate the ...", with the answer often looking/sounding like it was AI-generated (as of 2025 anyway). Take the blinking lights and panels in STTOS vs touch screens in STTNG - they were 'near future' depictions that each contemporary target audience could understand with limited explanation. But, then again, STTNG was quite prescient with the use of tablet-like devices and wearables, and may well be again with holographic storage, so why not a universe where users never had to worry about a file format? And are we really that far away from using a voice interface to, say, ChatGPT, starting with, "Computer ..."?
I think it's something to keep in mind - that files (as we understand a document or data file in 2025) and file formats may disappear behind the HMI at some point ... but I can't be sure and I don't know when.
If this really floats your boat then have at it: nit pick - I really don't care.
I suspect when Linus shuffles of this mortal coil there will be some fairly rapid and dramatic balkanisation.
Redhat (IBM), Oracle, Amazon and Microsoft all have heavy internal dependence on Linux, and the chance of them forming a standards committee rather than just going their own way seems slim.
Google already went off with Android.
Ubuntu might try to pitch themselves as the One True Linux, but they went with systemd, curse them.
I think Ubuntu will last until I don't need it any more, which is around a quarter century.
I would like to think Fortran survived my entire time on this earth, unlike C60, VHS and CD which seem to have come and gone.
C60, VHS and CD which seem to have come and gone
I refer the honourable gentleman to a recent discussion on that issue. And don't forget Vinyl, which never quite seems to die.
M.
> the last company I worked for was building new integrations (with Salesforce) based on csv file transfers when they could have used REST APIs.
Can't speak for that specific system, but if it works it works. You seem to assume the implementation results out of ignorance as opposed to explicit requirements and constraints.
25 years ago, our group was trying to set up a web portal for a large database using (then new) web application middleware. I had already had some bad experience with middleware in the late 90's and the middleware for this project didn't disappoint. Shit never worked right from the start and a month before we were supposed to go live, the server was core dumping all of the time, plus too many other bugs to count. It was obviously unfit for purpose and we had no confidence it would ever be.
With that knowledge, I proposed to the client that we simply do it ourselves using database stored procedures and a bog standard Apache HTTPD server. All of our developers knew database code and would be able to re-implement the already developed apps pretty easily. Still it was a big ask as that would involve redoing almost a years worth of development. I got approval an and managed to create a login page with authentication, plus exactly one web report. I used the html generated from the middeware as a template so at least it was good for something. And we went live on time with that one report.
Without all of the middleware crap, it was fast and reliable and our development group quickly developed the other reports.
For the last 20 years, they have been trying to replace that "legacy" website with something more modern. But 6 billion searches later, we are still using that same technology.
> 25 years ago, our group was trying to set up a web portal
How did the middleware get into the project? IME these things tend to occur when someone who is not qualified writes the requirements (either because he thinks he's qualified, because he doesn't know any better, or because he gets told to do it) or when the client (sponsor) or project owner insist that you use a specific solution whether or not that is supported by analysis or experimentation.
At least your client was sensible enough to let you try something else.
For program-generated documents that I want to appear "the same", I generate RTF. It's worked well for me for over 20 years now. The only hiccup I've had is with WordPad not understanding columns (I don't think it implements columns at all), but the content itself is correctly laid out and readable.
I convert all doc(x) files to odt before saving too. Usually, anything I send out becomes pdf to stop any of the ignorant changing it, not especially to make it look the same on all platforms.
My desktop runs archlinux, although I can't now remember how I set it up...
Me too: both the 'save as ODT', and the 'publication' as PDF. But for me the latter is a locked PDF, ie with a password being required for making any edits. Only rarely - and usually because of 'identifiable personal data' - is a password required merely to read the file.
The password-to-enable-editing is always a meaninless jumble of 10-15 characters: which I don't bother even to retain, being as I have the orginal files. If a document is 'over my name' then it is going to stay as I wrote it...
[PS: I've been around just a few years years longer: is it just we crumblies who are paranoid?)
CSV files are not safe at all for sending data.
A lot of text contains the character known as ',' or another character and implementations differ on unit separators and escape sequences (whether that's ''' quotes, or '"'quotes or '`' quotes or ',' or ';' separators) - meaning a lot of fiddling is required to do processing on a CSV file.
The worse case is where software is bugged and exported files don't escape ',' in any way - meaning any kind of parsing requires working working out the separators from the data.
ASCII was designed at the start with 4 characters that can be used to solve that problem (file separator, group separator, record separator & unit separator), but of course almost nothing uses them, as most font designers haven't bothered to implement a character for any of the visible ASCII control characters.
>Linux is forever. We'll still be running Linux come 2100. Heck, I won't be surprised to see computers still running Linux in 2125.
I'd go all in betting against that one - considering that Linux's licensing isn't even in order and it's also stuck on GPLv2-only (who knows, some court might make yet another error and rule that the GPLv2 is invalid or something) and how it keeps getting corroded more, with more and more proprietary software and its not great design means that I doubt it'll be commonly used in 20-40 years from now.
I guarantee GNU will still exist in 2100, despite all the attempts so far to destroy it and despite everything that will be tried next.
>Yes, I'm a big open source fan, and GIMP
Sorry to break it to you, but GIMP3 is free software again, as it supports the non-rust version of librsvg again.
>However, people who work with PDF a lot are painfully aware that there are many PDF variants
Free software pdf software has no problem handling pdf's that meet adobe's pdf specification (too bad a lot of proprietary pdf software, for example adobe's software, produces pdf's that intentionally violate the specification).
Thankfully GNU GhostScript can repair such sabotaged pdf's;
for pdf ; do
gs -o "${pdf%.*}_repaired.pdf" -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress "$pdf"
done
I'm typing from an IBM Model M Keyboard I bought for $1 at a yard sale in 1999. It's been a daily driver ever since. I imagine it will still be going in 50 years.
Speaking of which, I imagine, the QWERTY keyboard layout will still be around in 100 years as well, considering it's already about 150 years old.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
