Posts by MacroRodent 2015 publicly visible posts • joined 18 May 2007
Frequent travelers should have a separate cheap laptop to take along anyway. Even for other countries than USA, Russia, or China, because of the possibility of the laptop getting stolen. Copy only the needed documents to it before traveling, reformat and reinstall after the trip.
Never seen a failure in 5 years. I guess I have managed to avoid the bad ones, then. What I have are mostly Fujis, Maxels, TDKs, Sonys and Verbatims, but when one looks at the packaging, most actually came from some company named Ritek. I once did a small "accelerated aging" test, where I hung a sample of DVD-R:s on an outer wall, exposed to varying temperatures and sunlight. The winner? "Octron", which at the time was a house label sold in Lidl stores (havent seen it for a long time). But that too was really a Ritek.
> Everything else used either a lot of devices (like USB and SD cards) or wraps the media with a lot of hardware, IE hard drives.
Optical media (eg DVD-R) is also entirely passive. With good blanks and decent storage it also has good longevity. At least 20 years is no problem for in my experience (that is going by the oldest DVD-R's I have).
> This is one of those many cases where hacking the device you own should be legal,
Yes. A law that says something like if the vendor stops supplying software updates, it must either open-source the code and any keys needed to update the firmware, or offer to buy back the devices for 50% of the original price.
The Linux developers have no commitment towards keeping the internal C interfaces stable. They see such commitments as an impediment to improving the kernel. They don't change them unnecessarily, but they will change without hesitation when there is a good reason.
By contrast, the interface towards user-level applications (system calls) is kept stable.
> Every one of the dozens of proprietary UNIXes in the 1980s and 1990s had its own independent implementation, including Sun, Silicon Graphics, IBM, Apple, Commodore, Atari and Acorn, as well as dozens of implementations on DOS, Windows 3
I don't think the Unix versions were independent, just MIT X11 + whatever "value-added" the vendor wanted to add (often some proprietary desktop environment). DEC by the way added X11 to VAX/VMS and called it DECWindows, but it was still MIT X11 underneath.(DEC was also one of the major contributors to early X11). I actually at one time ran a remote DECWindows terminal window from a Unix workstation when I needed a session at the VAX, but that was a bit rude way of doing it, because of larger resource usage compared to a telnet session. So being a terminally nice guy I stopped doing it when I realised this.
> GNOME-based Workstation is the most visible, and it supports x86-64, Arm64 and 64-bit little-endian PowerPC
Now I got curious. What kind of workstation runs on a little-endian PowerPC? Or any PowerPC( excluding old Macs, which I believe were big-endian like the previously used Motorola processor).
That is a kind of "Your mileage may vary" situation. Someone at my workplace tried various filesystems for very large build jobs in a local cloud server, and BTRFS came surprisingly on top. Still, I myself prefer XFS, as a mature fs with long track record and good performance in most cases. The file system is the one component one does not want to play games with.
Might be a practical problem it the physics of turning a sonic boom into a sonic thump require the tapered nose to be half the plane even when scaling up. MIght work, but the passenger capacity in relation to the dead weight of the hardware would be ridiculously low. The seats would be super expensive. Of course they were on the Concorde, too, and it wasn't terribly succesful commercially.
> Depends on the time period and location. Modern-ish PCs will tend to use around 50W, add about 25W for a monitor so 75W per setup, for 1875W in total.
However, at startup these PC:s are, for a brief moment, almost short-circuits. If a lot of them are behind one fuse, and started simultaneously (such as after a power outage), the fuse blows even if during normal operation the current is reasonable.
Learned this when in a previous job we had a room full of various PCs and servers for testing purposes (not a production server room, fortunately). They had been placed there and started over time. Then a power outage occurred and the fuse blew when power came back up. Happened a couple of times before we understood why.
If the Chinese can build a smartphone with the usual goodies using only domestically made chips, even if it is two generations behind the latest Western tech, it means they have no trouble building modern missiles and drones with similar electronics. The latest process is not required for them, the one from 10 years ago is good enough.
Yes, but you should not execute an interactive editor to create the scripts. Tcl can write them directly. It can also easily do itself whatever any shell script needs to do, because it can execute external programs easily (exec "program" "args" ...). The second solution is usually better, as it has less moving parts. Creating a script from Tcl makes sense only if there is some other component that needs a script as input.
The way Tcl syntax works has always reminded me of shell with commands followed by space separated options and arguments. The main difference is of course Tcl does not start a new process for each command, and the code for each command is already in the interpreter instead of loaded from disk, which makes it much faster.
I don't really write Tck now, but there is one tool written it it that I always use and carry around: the graphical diffing tool tkdiff. It is amazing the whole thing is only about 16 000 lines of code, and can process quite large files in reasonable time, despite being written in an interpretive language. Of course much of the grunt work is done by the "diff" tool of the host computer, but making a nice display of the results is still nontrivial.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
