I only gave up my IBM Modem M-13 in the cubicle farm because the new PC they lifecycled me to didn't support PS/2 anymore and the PS/2 to USB adapter missed scancodes too much to be worth the trouble.
You can get a modern implementation of the IBM model M keyboard with a USB interface from Unicomp. https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.pckeyboard.com%2Fpag...
My memory may be hazy, but the Amiga filesystem could analyze files for content and use whatever you configured to open/edit/execute that file. Or nothing, if nothing was setup to deal with that file type. With a hex editor you could see in the first few bytes of a file what type it was. The Amiga filesystem understood file names with an extension as well.
My memory is also hazy, but I believe you are correct. The Amiga used the Interchange File Format, which was later developed into the Resource Interchange File Format, which is still in use today in WAV files.
True, I can (and do), but the OS certainly doesn't treat it that way; for example, the ren.exe command in DOS/Windows (or the mv command in Linux/MacOS) require me to always specify the type "attribute" along with the file's "name", and they will happily the change file's "type" (and not only its "name") if I'm not careful to specify it the same way in both arguments. There's no formal separation at all, only a standardized(ish) convention.
That is true of the command line, but at least some of the Graphic User Interfaces treat the text after the last dot in a special way. Windows Explorer hides that text, including during a rename. The GNOME equivalent of Windows Explorer shows you the file type but uses highlighting to invite you to change only the text before the last dot.
Doesn't that seem like a very natural way to use a computer with a file system?
The computer-programmer in me thinks mixing file-type information into the filename is a broken design; independent attributes ought to be kept in separate fields entirely. OTOH the computer-user in me thinks it's quite useful, for the reasons you mentioned. And finally, the pragmatist in me says that's just how things are, and even if someone came up with a better approach (many have tried), it won't catch on due to the black-hole-esque pull of backwards-compatibility with existing filesystems, so nothing can be done.
You can think of the dot in PROG.FOR as a separator between the file name PROG and its only attribute: its type, in this case FOR meaning a Fortran program.
P.S. Sorry, forgot all the other PDPs.
Actually, I was recalling my experience moving from the PDP-1 (paper tape) and the IBM 7090 and Burroughs B5000/B5500 (punch cards) to the PDP-6. However, the file type EXE wasn't used until the Linker was written for the PDP-10. Before that we used Loader, and saved the image it created using the file extension SAV.
This fits right in with the idiocy of hiding file extensions
What about the idiocy of using file extensions? It's smarter to analyze the files to determine their formats. For performance, you reasonably want to cache that information, and I was sure the filesystem would do that for us by now, but trusting the extension is just about the last thing you should do anyway.
File extensions were invented in the early 1960s along with file names. Imagine you are a computer programmer who has been storing his programs on punch cards or paper tape, and you are now using a computer with a file system. You have a Fortran program named PROG in a file named PROG.FOR. You use a text editor such as TECO to edit that file, which is a big improvement over editing a paper tape or punch cards.
To compile the program you apply the Fortran compiler to the file, having it write a file named PROG.OBJ. You then apply the linker to PROG.OBJ, having it write a file named PROG.EXE. You can then ask the operating system to run file PROG.EXE.
Doesn't that seem like a very natural way to use a computer with a file sytsem? If you think file extensions are idiocy, what would you propose instead for this scenario? Remember that there are no subdirectories, file names are limited to six ASCII upper case letters and digits (36 bits), and file extensions are limited to three ASCII upper case letters and digits (18 bits).
That would simply be a waste of time.
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.penny-arcade.com%2Fc...
The arguments in your reference are good ones, and I am sure that is true in some cases, but I have not found it to be generally true. I did see one case in which an editor claimed that he didn't need to cite sources because he was an expert on the topic. As I and the other editors told him, if the information he has is not available in a reliable source, he should publish what he knows in a peer-reviewed journal, and we will then be happy to cite that source.
Its not just news, Wikipedia isn't very good as a source on anything slightly controversial. The articles are written by a single person or a small group, and they fail to write unbiased. Personal opinions injected everywhere, which, according to Wikipedia is fine as long as you can find some source that says it. If you don't believe me, read an article on something you know a lot about and see how Wikipedia butchers it.
If you find such a butchered article I recommend you edit it to make it better.
Digital Equipment Corporation bought us to our computing place. Unix was written on DEC computers. PDPs inspired a lot of computers, such as the MC 68000 seen in the first Macs, all the way up to and beyond the SnapDragons seen in PDAs. DEC's VAX brought virtual memory, and also brought us memory-mapped hardware. It is a tragedy that there was no way forward--for a company that brought us so much. A nod for DEC.
I have many fond memories of DEC. I worked for DEC customers from 1963 to 1977 as a System Programmer, then for DEC until 1992 as a Software Engineer. Looking back my favorite projects were the DN60 communications processor and the EDT text editor. DEC took the small computer market away from IBM, but IBM survived to take the personal comptuer market away from DEC.
All we had on our PDP-11 was RSX-11
There were several operating systems named RSX-11: RSX-11D begat IAS, and RSX-11M begat RSX-11M-plus which was rewritten for the VAX as VMS. I think there was also RSX-11A, B and C.
...Scammers will also say things like "this avoids having to pay taxes" and many people will think this is sensible. Especially if the logic center of their brain is turned off that would otherwise say "a big bank like this would not casually flaunt the law and set itself up for prosecution."
On the other hand, there is Wells Fargo.
... I guess that means that the bad decision-makers' heads, who decided the built-in prompt rewriting and racism was necessary for DEI, are gonna roll as well.
It's not entirely all about training data causing the issue... It's been proven on youtube that you can ask for an image of a white married couple, and it will tell you it can't because of diversity and hate. But ask it for a black married couple, and it will gladly spit out 4 images of a happily married black couple.
It's bias is freaking ridiculous.
... While my father was technical in his day...post stroke, he's not quite as fast as he used to be...mom was never technical.
I identify with your father. I am a young 78 years of age and have not had a stroke. Even so, I am not as fast as I used to be. Time was, I could write PDP-11 assembler with both hands. Today I plod along with Python. I hope when I get old my son, who is much cleverer than I ever was, will be as kind to me as you are to your parents.
The entire problem is basically lazy programmers who want to pretend unix time is utc and let someone else deal with the problems*. It isn't. Changing to leap minutes actually makes this problem worse because it is even easier to ignore. Also the it being too easy to ignore is genuinely getting worse even with leap seconds. The idea was that there would be a leap second around once every 1-3 years, so everyone would deal with them regularly and it would be no big deal. But the Earth's rotation unexpectedly stopped slowing down, and then in 2020, started speeding up. (see this plot where the jumps are leap seconds) So there was no leap second between 1999 and 2006 and there hasn't been one since 2017 and there is unlikely to be one soon. There is actually discussion of whether we will need a negative leap second. That is in the spec, but has never been used and is almost never implemented because nobody thought it could happen. So the whole discussion of a leap minute is either essential or almost irrelevant because a negative leap second would break everything but we may not need one for 15 years or more.
* The problem being that the number of SI seconds between unix time of noon Jan 1 2020 (1577880000) and noon Jan 1 2010 (1262347200) is not (1577880000 - 1262347200) = 315532800, it is 315532803 SI seconds (including three leap seconds). i.e. you cannot subtract unix times to get a long time interval. Just like you can't subtract year*365+dayofyear to get the number of days between two dates. Unix time is not the number of SI seconds since 1970, it is the number of (utc) days since 1970 times 24*60*60. Exactly when those ticks happened on any given day is not well defined in the spec and different implementers have made different decisions (some repeat the last second of the day, some stretch the second for some amount of time before and/or after the leap second, sometimes the issue is ignored and the clock was just reset at some arbitrary time). Even the man page for "date" is misleading because the author was too lazy to sort this out and explain it. The simple fact is that a unix second and an SI second are not the same thing and the unix second is not even a uniform measure of time.
I am a fan of leap seconds, since I think they are a good solution to the problem caused by the rotation rate of the Earth not being uniform. Also, I agree that the difficulty in implementing leap seconds correctly is due to lazy programmers. To alleviate this difficulty, I have written a software library which manipulates time values, taking leap seconds into account. Lazy programmers are welcome to use my library, which I have made available under a free license. See Avoid Using POSIX time_t for telling time for the motivation, documentation and source code.
After all is said and done, a hell of a lot more is said than done.
