I wonder, have you ever read a novel? Hundreds of pages a single person wrote about a story that happened (usually) entirely in their head, printed on paper, no way to interact with it. It's a great experience if the author has some skill at this.
5,657 karma · joined August 28, 2019
https://goliath32.com/
https://github.com/AgentD/
https://hn-wrapped.kadoa.com/st_goliath?share
I wonder, have you ever read a novel? Hundreds of pages a single person wrote about a story that happened (usually) entirely in their head, printed on paper, no way to interact with it. It's a great experience if the author has some skill at this.
Yes, it's a GNU extension, but it's also supported by various BSDs [1][2][3], and yes, Musl has it too. It's present in pretty much any sane C library.
[1] https://man.openbsd.org/man3/printf.3
[2] https://man.netbsd.org/vasprintf.3
[3] https://man.freebsd.org/cgi/man.cgi?query=vasprintf&sektion=...
> ... in the comments everyone ignores the content and argues about the headline.
Surely you must be new to Hacker News…
... like in the PC AT, PC XT[1] or the Compaq DeskPro 386[2] that the article discusses didn't have those ports at all.
Those were instead on ISA expansion cards, just like the floppy controller that would often share a card with the UART controller for the serial interface.
[1] https://theretroweb.com/motherboards/s/ibm-xt-type-5160-64-2...,
[2] https://theretroweb.com/motherboards/s/compaq-deskpro-386-20...
It looks like not even Arch Linux had that version in their repo yet (currently 2.4.63-3) [1]
The videos I tried to transcribe were also Mandarin Chinese, using whisper-large-v3. Besides the usual complaints that it would phonetically "mishear" things and generate nonsense, it was still surprisingly good, compared to other software I played around with.
That said, it would often invent names for the speakers and prefix their lines, or randomly switch between simplified and traditional Chinese. For the videos I tested, intermittent silence would often result in repeating the last line several times, or occasionally, it would insert direction cues (in English for some reason). I've never seen credits or anything like that.
In one video I transcribed, somebody had a cold and was sniffling. Whisper decided the person was crying (transcribed as "* crying *", a cough was turned into "* door closing *"). It then transcribed the next line as something quite unfriendly. It didn't do that anymore after I cut the sniffling out (but then the output switched back to traditional Chinese again).
The PC AT (which had an 80286), later replaced the 8255 with an 8042 microcontroller too. It was running firmware, so re-purposing it for a Hodge-poge of other tasks became trivial. A single GPIO pin was used for masking the A20 line and another for handling CPU reset. Having a total of 24 programmable I/O lines, I guess this could have been done with the 8255 too, but the microcontroller probably allowed simpler interfacing with the CPU and bought them more flexibility for future expansion.
For the article, this is mostly irrelevant. As somebody else noted, the Xbox wasn't supposed to be able to toggle/mask the A20 line, but later x86 CPUs had already integrated the A20 masking feature into the CPU itself and exposed an A20 control line. The Xbox simply tied the A20 enable line to a fixed potential, the hack described in the article requires a simple hardware modification to change that (https://xboxdevwiki.net/File:Haxar-a20m.jpg).
From what it looks like, the difficulty shouldn't be in getting a board made or soldering them, but sourcing the parts. Other than the odd 74 series ICs, the design includes some (I think memory?) chips that are nowadays more difficult to find than the 6502 & 6520.
https://www.digikey.at/en/product-highlight/d/digi-intl/digi...
If you remove the "blog." subdomain and go to https://pipetogrep.org/ you are greeted by a typical "about me" page. It includes a link back to the blog, as well as a mailto link, and links to GitHub and LinkedIn profiles.
The visible human project has been around for quite some time and has, in fact, accomplished their initial project goals. And they do have a demo application, complete with a "guided tour", interview snippets and everything, all on a single CD-ROM! I remember playing around with it at the local library in December 2003.
... as a private individual, you are toast.
I think the more appropriate quote to paraphrase would be one from Dennis Hopper's character in the film Speed (1994): "Oh, no. Poor people are pirates, Jack. We are tech innovators!"
I recall having played around with DSL/TCL (Damn Small Linux & Tiny Core Linux) around 2010 or so and IIRC they already had their minimalist X11-but-not-Xorg server even back then, which I found fascinating at the time. I'm pretty sure I took a curious peak at the source code back then, IIRC it simply didn't live in git yet (tarball and a few patches?).
The XVesa code base that this is forked off of is of course much older.
...which is hosted on a different domain (notion.so), so if you didn't notice and temporarily allow that domain in NoScript, the actual page (hosted on kranga.notion.site) will still redirect you to the "Please Enable JavaScript" text on notion.so
I think I browsed through this at one point, but I don't have any experience with GW-BASIC myself. I had a copy of QuickBASIC and a print out of Thomas Antonis "SelfQB" at the time. He also runs http://qbasic.de/ from where I downloaded and (much to the annoyance of our schools librarian) printed out a bunch of other tutorials as well.
Back then, Antonis website served as a very useful entry point to other sites and tutorials. I remember spending a lot of time following rabbit holes of link lists and web rings from there.
At the time also posted on HN: https://news.ycombinator.com/item?id=31485616
It provides a few details on the software stack, particularly also the set of compat-APIs for porting Linux applications.
They're coming to take me a away haha
they're coming to take me a away hoho hihi haha
to the funny farm where code is beautiful all the time ...
-- Napoleon XIV, more or less...Via: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
2) This is especially bad if you want to do precise time measurements, a chunk of time is now spent just calling `gettimeofday`. The performance impact (benchmarked and shown in the article) is substantial.
3) Linux (the kernel) at some point added a "vdso", basically a shared library automatically mapped into every process. The libc can call into the vdso version of `gettimeofday` and use the system call as a fallback.
4) A 64 bit kernel that can run 32 bit programs needs a 64 bit and 32 bit vdso.
5) On x86, the kernel build process can "simply" use the same compiler to produce 32 bit code for the 32 bit vdso. GCC for ARM can't, for some reason. You need 2 toolchains, a 64 bit and a 32 bit one.
6) If you don't know that, the kernel kernel only has a 64 bit vdso, the 32 bit program will run but silently use the system call, instead of the vdso, causing unexpected performance issues.
Somehow we manage to piss away computing resources like nothing, requiring more and more to do the same work. So I guess for meaningful comparisons we need a way to inflation adjust computing resources too?
E.g. 5MB of 1965 disk storage, roughly equivalent to 10 TB in the eyes of 2024 programs?
Maybe we could draw a comparisons by how much a base installation of a recent OS would eat away, or how much of the available RAM an at-the-time-modern text editor would gobble up? E.g. 1980s Emacs vs whatever currently popular Electron behemoth to compare RAM on computers from those respective epochs.
As a result, the author has such strange, absolute positions, calling it a legacy that should be abolished (only tangentially knowing some actual use cases), or that strange quote about design principles.
Despite all the talk about security, the whole debacle that argc can be 0 (and argv[0] can be NULL), is completely left aside. This has caused actual security issues quite recently[1].
extern char *__progname;
which holds the program name without the (optional) invocation path in front of it. Basically the last path component of argv[0].With such tough competition, I guess https://www.hacker-stockphotos.com/ is out of business now?
The year is 2024 and I need to give a presentation. I walk up, plug the HDMI cable into my laptop. On my Xfce desktop, a window pops open with 4 buttons: Laptop only, external display only, mirror, expand. I choose "mirror", the desktop is resized to the smallest common size and it "just works". Unlike the next person who has to futz around their Windows settings for a few minutes and afterwards asks me excitedly what that tool was that I used.
Of course then there is also that one guy who fidgets around on stage for 10 solid minutes, before we are treated to a tiling window manager with eleventynine terminal windows and a hundred nervously fat-fingered xrandr command lines. Everyone in the audience chuckles and shakes their head "Linux people, typical...", and the guy on stage, already sweating blood begins the presentation.
But I guess you just gotta have your command line and complain about it too.
I know that on Linux, there are mmc-utils, but I only used those with eMMC so far.
I just tried to read out some general status information on uSD cards I have around: it didn't work for 2 Kingston and Acon cards (command timeout). But for a Swissbit card (industrial), it took some solid 10 seconds before reporting back that it's doing ok and is ready for data. Looks like it depends heavily on vendor support, possibly also undocumented/non-standard command sequences?
Yeah, MLC already losing data after 3 months doesn't really surprise me that much. If you play with a raw MLC chip and turn off the ECC engine, the amount of bit flips you get from reading on some chips isn't even funny anymore. With one chip I tried, even with ECC, I managed to induce persistent bit flips fairly quickly just by reading the same physical page over-and-over. For extra fun: those bit flips can happen in another page that you didn't touch, because the bits are paired :-)
What actually still does surprise me sometimes, is how reliable those things can work after all, if you just pile enough software abstraction and management on top.