Up next: forgotten Piet[1] autorun feature discovered in MS Paint. Customers complain after removal, insist they have existing legacy applications depending on it.
yes, e.g. the version of Windows 3.x and accompanying office suite that I used as a child had German words next to the icons. The idea of labeling a pictogram with text isn't a concept that suddenly breaks when using a language other than English.
> Colors and pictures aren’t exactly free of cultural baggage, either.
I remember being really confused that I had to click on a picture of a frying pan for "search".
So were you able to learn the skeumorphism eventually and equate the operation with the frying pan?
If I were in E.U. I would be afraid of needing to learn enough of 2 dozen assorted languages vs. learning an icon interface once. It would seem that human languages are not as inclusive or universal as icons.
You can do all the l10n you want, but who translates all of them and keeps current?
Sadly, it does not seem to boot on my 486 DX2, I even stuffed 32M of RAM into the machine (8*4M, maximum the mainboard supports), more than the recommended 20M.
I have copied the floppy image from the site. It churns for about a minute and a half, loading kernel and initrd, then says "Booting kernel failed: Invalid Argument" and drops into SYSLINUX prompt.
EDIT: I tried a few more floppies to rule that out as the cause of the problem.
EDIT 2: I cloned SYSLINUX, checked out the specific commit and did some prodding around.
The function `bios_boot_linux` in `com32/lib/syslinux/load_linux.c` initializes errno to EINVAL. Besides sanity checking the header of the kernel image, there are a few other error paths that also `goto bail;` without changing errno.
Those other error paths all seem to be related to handling the memory map. I know that the BIOS in my machine does not support the E820h routine. I have a hunch that this might be the reason why it fails.
Most of those machines seem to be newer systems which probably support E820h, except for another 486 DX2 with a similar vintage as mine, that also failed to boot.
What’s your board and BIOS? Syslinux 6.x COM32 Linux loader
goes through the memmap layer syslinux_memmap_find() to place the kernel/initrd. If INT 15h E820 is missing and/or buggy on a 486 BIOS, it can surface as “invalid argument”.
For my 486 distro[see snacklinux.org], I use syslinux 4.07 due to similar issues. I never had any luck with syslinux 6.x, I’d recommend a similar path. It always seems funny to me when I see similar projects, claiming it runs on 486 hardware but rarely do I see people actually doing that, and just fire up qemu instead. Running Linux in a vacuum isn’t realistic, especially when we’re talking old hardware and configuring IRQs manually.
It is running some AMI BIOS variant with a copyright date of 1992, I currently don't have the exact version string around to compare with the ROM dumps on retroweb. vbindiff says the "F" and "M" images are identical and the "H" only has a few 1-byte differences, mostly typos in ASCII strings.
I've written a small boot sector program once that tries out memory and CPU information gathering techniques, so I know the INT 15h, E820h, E801h are not implemented but INT 12h and INT 15h AH=88h return something sane. When I have more than 16M installed, the later reports the full 31M of HIMEM, but I'm not sure how the ISA memory hole factors into this.
From what I saw glancing at the scanning code yesterday, syslinux 6.x should fall back onto AH=88h if AX=E820/E801 doesn't work. It's interesting to know that this worked in older SYSLINUX, I'm curious to check out what changed.
Yeah, even if syslinux 6.x “falls back” when E820/E801 aren’t there, AH=88h is just a number, not a hole aware map. It can’t describe ISA/ROM/reserved regions, so the loader still might not be able to build something it trusts.
If you want to prove it yourself, stick a log right around syslinux_memmap_find() and dump the memmap entries it thinks it has on that BIOS.
Its interesting to notice that syslinux 6.03 had a fix for your same issue:
"Fix hand over to kernel:
"Booting kernel failed: Invalid argument" error."
https://www.linuxquestions.org/questions/slackware-14/%5Bann...
Based on the POST strings of your motherboard versus mine (https://theretroweb.com/motherboards/s/fic-486-jal-rev-c), we both have an AMI BIOS so I might be able to run a similar test for my board. You're right that syslinux 6.x should fall back if E820 doesn't work but that hasn't been my experience on my motherboard hence the reversion to 4.x, I can reliably boot with 4-16MB of RAM.
You might be thinking of ar, the classic Unix ARchive that is used for static libraries?
The format used by `ar` is a quite simple, somewhat like tar, with files glued together, a short header in between and no index.
Early Unix eventually introduced a program called `ranlib` that generates and appends and index for libraries (also containing extracted symbols) to speed up linking. The index is simply embedded as a file with a special name.
The GNU version of `ar` as well as some later Unix descendants support doing that directly instead.
Yes, one can only hope Ken Shirriff eventually happens to come across one of those models, but I guess they are probably very rare these days.
Besides the multiplication, the 386 had quite a number of teething problems[1], including occasionally broken addressing modes, unrecoverable exceptions, virtual address resolution bugs around the 2G mark, etc...
A while ago, there was also an article posted here that analyzed the inner workings of the Windows/386 loader[2]. Interestingly, Windows simply checks a pair of instruction (XBTS/IBTS) that early 386 steppings had, but was later removed, raising an invalid opcode exception instead.
Raymond Chen also wrote a blog post describing a few workarounds that Windows 95 had implemented[3].
From what I've read, the 386 multiplication bug was a semi-analog problem, so the fix was probably making a transistor larger. As a result, it would probably be hard to find the fix on the die and wouldn't be as interesting as, say, the Pentium division bug.
This reminds me of a problem from undergrad computer architecture: how can you validate the multiplier without checking all possible N squared inputs? (Which would take forever.)
I read later in a TI DRAM report about which bit pairs to exercise, based on proximity in silicon layout, to verify the part. I suppose something like that to stress-test the ALU.
Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement.
When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.
It is still crazy to me that intel though having 2 1 byte instructions for something that could just be coded as a single add with immediate instruction (which they had anyway).
Uh, before I wrote my sibling comment I read 'comment' as 'commit' and because of it I somehow assumed it was a github link... not sure how that happened.
Anyway, the user named 'soc' on HN has "listbite" in the description. I saw this profile, but I think it's not the same guy. But also I wasn't sure so I didn't paste the link to HN at all.
...only know what an inductor is from watching a video one the youtubes where they were talking about using them on the suspensions of F1 cars and they explained their relationship to electronic circuits, forget what their actual name is.
> how to exceed the normal limits on Linux kernel modules.
Uh, what limits? I'm not aware of anything that would stop your module, once probed, from reaching around the back of the kernel and futzing around in the internals of another driver/device in a completely unrelated subsystem, or subsystem internals. SoC/SoM vendors love to pull that kind of crap in their BSPs.
> hooks the VFS to allow dynamically remapping file paths on a per process basis
Instead of messing with kernel VFS internals, you could try:
- patching the offending application or package (ideally make the path configurable and contribute that back upstream)
- running the application in a mount namespace and bind-mount something over the path
- use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)
> use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)
I think I would literally recompile libc to patch fopen/open/openat long before I would even begin to consider writing a kernel module to mess with filesystem paths on a per-process basis.
I feel like if you find yourself seriously considering writing a kernel module then you are either contributing to kernel development, or have embarked on an adventure specifically to learn about kernel internals, or have take a very wrong turn.
Yes, I am aware. I was suggesting that even going to the ridiculous length of patching and replacing libc system wide would likely make more sense than authoring a custom kernel module to accomplish most tasks for which such options are applicable.
Statically compiled binaries don't use libc. Golang is one, anything with Rust and MUSL is another, and reliably injecting an environment variables into Nix is well..not reliable. It also links its own hashed libc paths which you can't predict and which shouldn't be different to any process which isn't trying to establish TLS connections.
You can hook the system call to open a file regardless of libc use. If for some strange reason you really wanted to patch libc and the program you're using statically links it (ex musl) that isn't an issue - just patch the relevant libc implementation and recompile. But more generally, if you have access to the source code then why would you not directly patch the program in question instead of resorting to these sorts of shenanigans?
Seriously, you're doing it wrong. Just hook the relevant system call and be done with it. Your usecase is literally one of the first eBPF tutorials that comes up when looking for information about modifying system call arguments. https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/m...
It’s hard to know for sure what’s acceptable when it comes to working conditions in China. The information we get is incredibly limited. Most of what makes it through is propaganda.
That said, it wouldn’t surprise me if he does it all day long, 6 days per week.
They are, there's a video on YouTube you can find where they interview someone with that job and they test 10,000 a day. Then they mention that they go home and vape some more
That’s much less automated than I would have thought. Also the dude vape testing the sticks… I don’t think they are aware they are probably doing more damage than good.
It's not that surprising that a company that sells these awful gadgets to people who don't really care about their own health would behave in such a manner.
[1] https://en.wikipedia.org/wiki/Esoteric_programming_language#...
reply