Posts by MacroRodent 1994 publicly visible posts • joined 18 May 2007
Outlook's Web version, which (being a Linux user) is the only one I use, does have a simple way to show headers when the mail message is being viewed: Three-dot menu -> View -> View message details. This shows the headers, but not the raw message data. Useful for checking suspicious mails.
> So dBase had two blocks of memory: a core block in memory, and an overlay block
Overlays is how many large programs worked, also on MS-DOS. The Microsoft linker had support for specifying which object files were part of the fixed block, which could be swapped in when functions in them were called. I never did CP/M development, but I suspect it had tool kits that did the same. After 32-bit 386 and its successors became common, large MS-DOS programs started using DOS extenders instead of overlays. Much easier for the programmer, and more efficient.
Those were the days when even well-known netizens did not yet get avalanches of mail, and spam was still almost non-existent. So they were more disposed to answer interesting mails.
I once mailed a minor bug in an early version of GCC to Stallman, and he quickly replied with a patch. That was probably around 1990.
Remember copying the original Minix floppies among some friends. Each had bought the Tanenbaum book, then we pooled money for getting one copy of the OS. As I recall ast wrote he and the publisher were OK with some copies of the software being made for study. The version of the kernel on the floppies was not quite the same as printed in the book, but slightly updated one. Managed to run in on a PC/XT clone. It did not even require a hard disk.
VirtualBox also checks for updates from the mothership. I would not be surprised if the check includes information about the possibly installed extension pack. So you could be in trouble if you load it at home but use it at business.
Pro tip: most ordinary usage of VirtualBox does not actually require the extension pack.
Anyone who has been doing real software projects knows that getting complete specs and implementing them in a predetermined timetable is a total fantasy.
You need flexibility, and Agile recognises that. But swinging too far in the other direction does not work either, except for very small projects.
Any project that produces working results is in reality a mix of "waterfall" and "agile", no matter how it is officially presented.
Many a science fiction story gets around this with the "Buzzard ramjet" that runs on interstellar hydrogen. If it worked, it would be able to accelerate forever. See "Tau Zero" by Poul Anderson, where this idea is taken to infinity, and beyond...
> What is needed is a server which, when asked, gathers up the WIMP stuff and squirts it down a pipe
That is essentially what VNC does, and with surprisingly good performance, if you use a modern VNC client-sever pair like TigerVNC. You can get servers and clients for various OS'es.
> each of which must represent 8 columns of whitespace.
Actually it varies: In terminals and printers, a TAB character classically moves to the next divisible-by-8 position. So if the current cursor or print head position is column 15, it moves to column 16, not 23.
Unfortunately various IDE:s practice the Abominable Heresy of by default setting TAB to advance to the next divisible-by-4 position instead. When a file written by such is viewed on a terminal or an editor Configured Correctly, it looks horrid. This wileness has forced the coding standards in my workplace to degree that only spaces shall be used for indentation...
Loongson is really a modified MIPS clone, and MIPS is a clean RISC architecture. Linux and other free OS'es have supported it for a while, so arguable it is rather open, and likely to have less vulnerabilities like the complex Intel architecture, with its decades long trail of backward-compatibility. The interesting question for security is does Loongson have a separate closed system processor with "superpowers", like most Intel and AMD ones do. That is where one would hide backdoors, if there are any.
About that ">I spent much of 1999-2004 porting software to it, which was a prime waste of time and money. "
I wonder how much of it really was due to Itanium quirks, and how much the general hassle of porting code that has too long assumed "longs" and pointers have the same 32 bit size?
If the latter, then AMD64 would case the same pain, and work on making code 64-bit clean for Itanium is not wasted.
I skimmed Andres Freund's explanation of how the backdoor was surreptitiously added, and one thing that in my opinion greatly helped the bad guys is the complex build process, typical of autoconf-using builds, where it is easy to hide bad stuff among the ton of shell command snippets and obscure m4 macros.
Defining how a piece of software is built could and should be much simpler, preferably with a purely declarative control file. Any yielding of control to arbitrary scripts is a risk.
> Instead of GNU, Linus could easily have used the open source 4.4BSD-Lite userland.
IIRC that did not include a usable C compiler targeting 386. The PC BSD versions have always used GNU C, except for shifting towards LLVM in recent years.
The development tools used for 386BSD (which was the first free BSD on the PC) is described here: https://www.drdobbs.com/open-source/porting-unix-to-the-386-language-tools-c/184408529
I haven't read the book (definitely will fix that), but if it describes a galactic network, the Usenet style of networking could still make sense, if the bandwidth is limited and/or there are long latencies.
(But I assume the network uses some sort of "ansible" technology to avoid making the latencies centuries long).
Populist right-wing governements never fail to promote a policy that sounds great to their base, but is invariably wrong-headed.
Same thing with the current Finnish governement. Here, too, all technology companies are aghast at their proposed immigration policies, just to mention one example.
> Linux today is about making things more cumbersome ...
Easy to think that way, but Linux is encountering the real world, and new requirements that did not exist back when the original Unix was designed. The original design was simple, elegant - and quite inadequate for today's tasks.
And like any old system (more than 30 years by now), Linux has to maintain enough backward compatibility, in order to not lose its user base.
This is a huge plus for privacy!
With server-based translations, you are telling some third party (over a channel that ma be intercepted) precisely what you are reading on the net. Usually it does not matter, but sometimes could be a matter of life and death.
> Need to tweak swappiness, or make another system-wide change -- tough.
I have not looked into how these work, but it certainly would not work well if you cannot change such parameters. I always imagined a read-only root fs just means the code and seldom changing data (like zoneinfo) is immutable, not the configuration data.
The requirement of TPM 2.0 chippery, which is may be missing on even relatively new computers, is criminal.
This means lots of perfectly usable PC:s and laptops will be junked, since they cannot be upgraded to Windows 11.
(Or one could be optimistic and see it as a pool of hardware that can be assimilated to the Linux world).
>No, the best option is to NEVER buy an HP.
Must confess I have kept buying HP printers because they usually have problem-free Linux support (or at least as much as that is possible with printers).
Not long ago I considered Epson Ecotank line, but browsing forums, it looked like trying to use them with Linux would just worsen my high blood pressure.
> Some writers did not like the Algol 68 convention of writing words backwards for closing statement brackets,
The original unix sh (shell) and its clones like Bash still do that. "if" is terminated by "fi, and "case" by "esac" (but curiously, "do" ends with "done", not "od"). Wonder if the style came from Algol 68? It was probably a hot topic around the time the sh was designed.
Thanks!
Pascal was the second programming language I encountered, after BASIC. The introductory programming course at HUT in 1981 used Wirth's "Algorithms+Data structures = Programs" as the text book.
I also dabbled at one point with Modula-2 (but not much as much as a more clever friend of mine, who used it to implement a universal diskette reader for a CP/M machine he had built from a kit).
Turbo Pascal was so popular that at one point Microsoft had its own competing version, QuickPascal, which also came with a IDE and compiled quickly. I guess it did not sell too well. because I got a copy cheaply from the discount shelf of a computer store in Helsinki. I think it was around 1990 or so, The language was mostly similar to Turbo Pascal, but not exactly so for some reason. In particular, the OO extensions differed.
Part of the reason for the lack of named file access in PASCAL was perhaps portability, in those days every OS had its own notion of file name syntax, and they were even more divergent than the tension between Windows and Unix/Linux file names.
It is also clearly meant for a batch environment. In the original, your PROGRAM statement could have file-type parameters and your "control cards" were expected to assign them to real files.
Another place where the batch-orientedness shows is that strictly-speaking the original did not even support any interactive IO, because notionally opening a file read the first element from it, so that INPUT^ which denotes the next unread element (usually character) would always have a defined value, and this INPUT (correspondings to C's stdin) was opened when the program started. So the program could not print a prompt before it required input!
Most implementations used "lazy IO", where INPUT was notionally opened at first reference. I think Turbo Pascal solved this by eliminating the silly file^ syntax entirely and required always using READ. A sane solution.
One implementation, PAX, that I had to use at the HUT (where it was written) took alternate route: The INPUT would always begin with a fictional line-delimiter, so to read from the terminal you would have to write
READLN;
READ(whateveryoureallywantedtoread);
Thanks, but that made interactive PAX programs automatically incompatible with all other implementations.
Nano is really a GPL re-implementation of pico (which IIRC was under not-quite open license), MS could probably easily reimplement their own. The nano UI has the nice feature that you can use it with zero previous experience, because it always shows the most important commands (of type ctrl-something) at the bottom of the screen. Great if you only need it occasionally.
> "As part of the contract's design, work with the RCCTO to transition Leonidas into a future program of record after successful demonstration of the prototypes," Epirus said.
Just ship some units to Ukraine, they will field-test them for free under real battle conditions, and return quick feedback...
Back when IBM-compatible monochrome monitors were a thing (remember those? green and very slow phosphorus, well at least it did not flicker), I encountered a warning on a 3.party extended graphics card (one that could drive both monochrome and CGA monitors with more colours and resolution than IBM's offering- this was before VGA and even EGA) that one should never use out-of-spec modes with a monochrome monitor, else it may break. So I did not. I have ever since wondered if this actually happened to anyone.
> Windows 3 and previous had Write so Windows 95 needed something like it.
When Windows 95 with WordPad came, I recall it actually had even less features than Write. For example, Write supported headers with page numbers. I actually wrote some report in a university course with Write on Windows 2 (yes, really) to see what these new-fangled GUI programs were about. Went back to LaTeX...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
