5,657 karma · joined August 28, 2019
https://goliath32.com/
https://github.com/AgentD/
https://hn-wrapped.kadoa.com/st_goliath?share
https://en.wikipedia.org/wiki/Intellec
The second sentence in that article says:
> The Intellec computers were among the first microcomputers ever sold, predating the Altair 8800 by at least two years.
For ext4, I recently saw a patch set on the mailing list[4].
Not sure about other filesystems tough.
[1] https://manpages.debian.org/unstable/squashfs-tools-ng/tar2s...
[2] https://manpages.debian.org/unstable/squashfs-tools-ng/sqfs2...
[3] https://manpages.debian.org/unstable/squashfs-tools/sqfstar....
[4] https://lore.kernel.org/linux-ext4/20230812150204.462962-2-j...
Wait what? I've soldered SMD parts smaller than that, I guess I could do 3mm lithography free-hand with a good razor blade.
Sounds like I'd have a nice head-start in the "cutting-edge" field of sub-centimeter lithography.
On an embedded device, you might have a piece of NAND flash directly attached to the CPU e.g. via a parallel bus or SPI. Usually with a controller somewhere in between, or integrated in the SoCs.
In Linux, there is a subsystem called MTD (memory technology devices) for dealing with not-quite-block storage that provides a thin hardware abstraction layer with an internal driver framework for NAND flash and backends for all sorts of controllers.
Some particularly cheap flash chips/controller do not support hardware bit-error correction. There are IIRC 2 software engines that a driver can use as a fallback: hamming and BCH[1] based (the former is documented here).
The MTD subsystem is really just a thin abstraction layer tough and provides a uniform API for e.g. page read/write & block erase for the flash chip it talks to. There is another subsystem called UBI (Unsorted Block Images) that can be stacked on top of MTD. It takes care of wear-leveling, bad block management and implements LVM-style logical volume partitioning. It also does not emulate a block device, but acts more like a flash device with idealized properties.
There are 2 filesystems in Linux which are designed to deal with the weirdness of those devices: the older JFFS2, which stacks directly on top of MTD, and UBIFS on top of UBI.
The way it was introduced to us, was to basically apply a parsing grammar backwards, IIRC using an iterative match-and-generate approach, to produce a command stream for a renderer.
I remember finding the idea of using a parsing grammar in this way quite interesting and wondered about other areas where this could be used. For some reason, programmable shell-completion came to my mind, i.e. encode a command line options for a program using a recursive grammar with "expand a file path here" or "call an external helper (e.g. git)" as terminal symbols. Throw in capture groups for terminals and this kills most use cases where the imperative approach in Bash gets very tedious.
I keep recalling that idea from the back of my mind every time I see L-Systems featured on HN. I guess/hope most newer shells learnt from Bash and already do something like this, but I honestly was just too lazy to investigate this any further (so far).
That, plus of course the obligatory blue/green cold-cathode tubes :-)
The whole point is pulling peoples legs, the joke being on the person who doesn't know the language well enough and takes it serious.
The answers in the list are the equivalent of telling an apprentice to go get a can of blinker fluid (or Siemens Lufthacken, etc...), which they dutifully do and end up getting laughed at.
E.g. just before the one you quoted was this gem:
> 1.8: What's the auto keyword good for?
>
> Declaring vehicles.
Regarding your question:
> How is this a good example of hexadecimal input?
It isn't. In C, a leading zero in an integer literal means octal. It compiles and works out, because `7`, `07` and `0x07` happen to have the same value.
When you hear a toilet being flushed in a movie, it is the exact same stock sound. It makes me realize immediately, that I just watched an actor walk in frame (sometimes fidgeting with their belt), while the effect was added later during editing.
Same thing with doors. For a long time, movies and TV shows have pretty much universally used the exact same stock sound of a door being closed. The sound effect is fairly recognizable and about as subtle as the Wilhelm Scream. Sometimes, you can even see that the door is not fully closed, but we still hear the latch snap in place. Sometimes it's also fairly obvious that this kind of door can't possibly produce that kind of sound.
I guess people working at the studios have realized that too at some point, and in the past years increasingly (but not completely) moved to a different, more subtle door sound. It's now become a bit of a "will they/won't they" moment of suspense, whenever I see a door prominently in frame for a character to walk through it.
The Bell Labs Holmdel Complex is something that I find myself unexpectedly stumbling over on the Internet every few years or so. First time some circa 10 years ago, when they uploaded a 1973 era training video for the computing services to `AT&T tech channel`:
> In 2019, libjpeg-turbo became the ISO and ITU endorsed reference implementation for the JPEG format. [13]
The paragraph that follows might help to clarify why this happened.
But AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2].
Even worse, the article doesn't even mention TIOCSTI, which is another big reason, you should not use `su` this way (see e.g. https://www.errno.fr/TTYPushback.html).
The program run under su keeps the same TTY and can use the TIOCSTI ioctl to push data back into the TTY input buffer. When the program exits and the parent reads from stdin, it receives those bytes. If the parent happens to be a root shell from which you dropped privileges using su, you have a problem.
If you're already a TV Tropes addict, I can strongly recommend the book.
[1] https://tvtropes.org/pmwiki/pmwiki.php/Literature/HowNotToWr...
[2] https://www.amazon.com/Write-Novel-Them-Misstep-Misstep/dp/0...
But not because of programming experience, but because of late-night Taxi drivers who drive like Doc Brown (https://youtu.be/vHake6w4Su0?t=17) and believe that "reverse" is some kind of cheat code that flips the direction of the road.
Also, cyclists.
Yes, e.g. LRO launched in 2009 (https://en.wikipedia.org/wiki/Lunar_Reconnaissance_Orbiter)
> this would easily put the conspiracy theories to bed
no, you are dealing with people who nit pick data, rejecting anything that does not support their position as falsified.
Attempts at reasoning are in my experience often met with emotion and ad hominem responses (e.g. the classic comparison to species of Ovis). Logic does not apply here.
The article doesn't seem to cite any new sources other than people speculating on twitter/mastodon. Following down the social media rabbit hole, I end up back at the article that sparked the debate 5 days ago. Some RFCs and product data sheets are cited to support the back-on-the-napkin calculations (also cited from social media), but do we have any credible source yet to confirm that's what really happened here?
The Venus driver for Vulkan is described as "experimental" [4], with Linux kernel side support merged in version 5.16 (release in early 2022[5]).
RedHat is developing VirtIO drivers for Windows[6], but apparently they gave up the work on the OpenGL ICD driver in favor of Vulkan[7]?
That said, I have no clue what the situation on various BSDs looks like. I guess on OpenBSD, this is a first step towards making this chain work?
[0] https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler...
[1] https://docs.mesa3d.org/drivers/virgl.html
[2] https://kernelnewbies.org/Linux_4.4
[3] https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg027...
[4] https://docs.mesa3d.org/drivers/venus.html
[5] https://kernelnewbies.org/Linux_5.16
[6] https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_...
[7] https://lists.freedesktop.org/archives/virglrenderer-devel/2...
Virtio GPU is something different, namely a para-virtualized graphics adapter that uses the VirtIO guest-to-host communication to expose hardware accelerated graphics to the VM.
For instance, on the guest side, you could have Mesa3D implementing OpenGL userspace and internally using its "Virgl" driver (or "Venus", for Vulkan) that serializes a command stream, sends that through a guest side kernel driver that passes it on through the VirtIO device to Qemu on the host side, that then uses existing OpenGL userspace graphics APIs to do the actual accelerated rendering.
I myself am mainly a C programmer, doing low level stuff, with occasional detours into C++ projects.
In 2019/2020, I worked on a larger project replacing a web based UI on an embedded device with something Qt based, not having touched Qt since version 4. Due to some of my older spare time projects, I have somehow become the go-to graphics guy in our company, but usually those issues revolve around questions like "why does the display bridge do those bizarre things?". This projects was IMO a quite interesting excursion outside of fiddling with graphics drivers.
Yes, I was a bit put of by Qml at first too, but eventually found it a breeze to work with. Qml is a language for designing both the UI layout and UI level interactions. Writing code and trying it out was a very refreshing change from having to fiddle with some IDEs Visual UI designer. I managed to cobble together complete mock-up clone of some of the existing UI screens in only an afternoon, rather than e.g. 3 or 4 days as originally budgeted in some cases, spending the rest of the time on "fine tuning" and starting with the back-end integration.
Combined with Qts emphasis on Model-View-Delegate design this allowed us to very cleanly separate the UI from the actual logic, to the point were the UI would work like a LEGO brick stuck on top of the application logic.
Even as a die hard C programmer, I would say I liked working with Qml and it is definitely something they did right.
The book briefly outlines Lovells early life and career as a test pilot up to the Gemini and Apollo programs, and the Apollo 8 mission before spending the bulk of the book recounting Apollo 13.
Even on the earlier missions and programs, the book is full of interesting tidbits, anecdotes and explanations. Particularly with Apollo 13 it is IMO quite gripping to read about the myriad of issues that came up and how they were discussed and dissected on the ground to systematically come up with a viable solution.
From the movie adaptation, I guess one of the more commonly know issues was the LiOH CO2 scrubber, where the CSM canisters didn't fit into the LEM. While apparently a lot less dramatic in real life, there were tons of other issues that the movie glossed over, from accidentally loosing navigation data while moving over from one computer to the other, the two course correction burns that were needed, exploding lead-acid batteries on the LEM, etc...
Anyway, as I said before, it's IMO a good read and I can strongly recommend the book.
Those might also qualify to some extent as "public USB port", although strange USB devices are obviously a well known security risk at this point (I hope).
I'd say the good old osdev wiki: https://wiki.osdev.org/Main_Page
Also, the Linux boot strapping code is a good read (arch/x86/boot), especially since this is actually used in production for at least 2 decades or so.
But really, it helped a lot having fidgeted with this countless times when I was 15, being obsessed about writing a tiny OS. So I knew what had to be done and where the journey would go.
> What would you estimate was your time investment to get it working?
Getting the MBR and VBR to work: About a weekend (again, with the unfair advantage of having done this in hand written assembly dozens of times before).
Getting the FAT code to work: A few more weekends staring at hex dumps and maybe some nights and a few cleanup/restructure phases in between.
The main road blocks typically involved stumbling into one GCC or BIOS oddity after the other (the way GCC generates 16 bit code, getting the inline assembly snippets to work, BIOS touching registers it shouldn't, mangling the stack pointer, using my stack a scratch buffer...). A hand full of times, the CHS arithmetic was off, occasionally I had to choose a different approach because I ran out of space.
The code doesn't actually do much and it mainly required the right amount of stubbornness to get it running.
Maybe they just want to commemorate the birthday of the visionary leader who recognized and funded the genius inventor that ultimately ended up being instrumental in getting the American space program of the ground?
/s
It works if you write multiple UTF-8 code-units in one go, but breaks if you send them in several writes (and by that, I mean direct writes to the HANDLE). It also breaks if you try to use the ANSI API (with the A suffix), as it internally tries to convert the bytes from codepage-random to UTF-8.
You run into both issues if you try to use the MS implementation of stdio (printf and friends).
And we didn't even discuss command line argument passing yet :-)
I had a lot of fun with this (more explanation in the issue comments): https://github.com/AgentD/squashfs-tools-ng/issues/96#issuec...
I tried to test it with the only other two languages I know besides English: German and Mandarin. Specifically also, because the later requires multi-byte characters to work. Getting Chinese text I/O to work at all in a Windows DOS box, on an existing, German Windows 7 installation was an adventure on it's own and ended up breaking things in different ways than German text.
Turns out, trying to write language agnostic command line applications on Windows is a PITA.
A really cursed implementation could hack up compiler support for an asymmetric integer type that treats all-bits-set as -1 and everything else as a positive number, allowing ssize_t to hold all but the largest size_t values. While perfectly standards compliant, I guess this might break a bunch of implicit assumptions across various existing programs.
If you want broadcast-message-to-topic-subscribers style semantics, you could have [ab]used IRC for this, rather than SMTP :-P
Granted, many of their research topics at the time are now no longer considered AI topics, part of what ultimately lead to the AI winter at the time.
Particularly because of that connection, however, I think it could indeed be interesting to hear some more from his perspective on developments in recent years.
It starts to matter the moment we teach people at large to call calculators "Artificial Math Professor", projecting the image that they do indeed comprehend mathematics at a higher level.
It starts to matter when I meet my aunt (a psychiatrist no less) for lunch and she is absolutely convinced that there is a conscious, intelligent entity living inside her calculator, and she wants to debate the ethics of this with me, getting angry and upset when I doubt the premise.
It starts to matter when I turn on the TV later that day and see our countries minister of education in a panel discussion, debating the future of our schools when AMPs will teach math to our kids instead of flawed, human teachers.
It starts to matter when our government starts debating new laws about "spreading dis-calculation" on social media, convinced that we can just let AMPs read and comprehend all those maths posts in real-time, reporting them to higher authority for posting wrong-calc, deciding on human lives in full-auto-mode.
It starts to matter when I discuss the above with my mother (a lawyer) over lunch and she doesn't understand what the problem is either, convinced that we actually have flawless AMPs that can do all of this, baffled that I, supposedly a "tech guy", am opposed to legislative decisions ushering in new, fancy hype tech.
It starts to matter when this is brought up on places like HN and people with a level of actual technological knowledge, possibly involved in some of this, fail to see the consequences and instead focus on high concept, philosophical debates about what really constitutes a "math professor", constantly moving goal posts around, hooked on their their own hype, rather than marveling the wondrous new technologies of the last years, but for what they actually are.
For people at large, a computer has always been a magic black box that they anthropomorphized anyway. When marketing starts using fancy SciFi words, re-defining their actual meaning to stir up hype, people happily go with the literal meaning of what they are told (as intended; hence the hype). They are absolutely willing to believe that we indeed trapped a Math Professor in a box, Max Headroom style.
Some of the people happen to be in places were they can make decisions, and that's when it really starts to matter.