MIR?
The article left it a bit unclear what is the relationship between Mir and Wayland. Is Mir running on top of Wayland? Or is is a separate implementation?
1981 publicly visible posts • joined 18 May 2007
> 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...
Once coded shellsort in 8088 assembler in one of my first computer jobs. It is not much more code than bubblesort and performs a bit better when the number of items increases. But in that particular application (crude 3d computer graphics) it probably did not make much difference, we did not have very complex scenes. But made me feel a guru...
Exactly. This is why a successful businessman is likely to be disastrous in a leading political position in a democracy. I wouldn't go as far as disqualifying them, but before someone can be elected to be a president, he should have succesfully served a term in some elected position, even if it is just a local councilman.
> My shop's dev infra is Rocky (previously Cent, natch) and prod infra is RHEL.
Out of interest, have you (or others here) looked at CentOS Stream? One would assume it would be good at least for dev infra. RHEL bug-for-bug compatibility is really an issue only if you depend heavily on 3.party closed-source packages, which I feel is an anti-pattern anyway for Linux users.
If it is a consumer router, the users likely are no aware of the problem, and will not become aware of the problem, as long as the router works for them. TP-Link and other similar consumer gear makers have no idea who their customers are, and cannot reach them. Probably they would have to be either forcibly remotely updated by some white-hat hackers, or remotely bricked, so that the oblivious user is forced to get a new one.