aleden

Yes! This is along the lines of what I thought of when I saw ghostty.

  https://news.ycombinator.com/item?id=42524537

EDIT: I seem to vaguely remember something similar to this concept from some anime I watched that depicted a "hacker". It might have been serial experiments lain, or cowboy bebop..

If you spent enough time and energy on it.. I'm fairly confident you could get the newest Ubuntu running. You'd have to build your own kernel, manually generate the initramfs, figure out how to and then flash it. You'd probably run into stupid little problems like the partition table the flash script makes doesn't allocate enough space for the kernel you've built.. I'm sure there would be hiccups, at the very least, but everything's out there to do it.

You could install Ubuntu 24.04 using debootstrap. That would just get you the user space, though, you'd still have to build your own kernel image.

Are you aware that mainline linux runs on these Jetson devices? It's a bit of annoying work, but you can be running ArchLinuxARM.

https://github.com/archlinuxarm/PKGBUILDs/pull/1580

Edit: It's been a while since I did this, but I had to manually build the kernel, overwrite a dtb file maybe (and Linux_for_Tegra/bootloader/l4t_initrd.img) and run something like this (for xavier)

  sudo ./flash.sh -N 128.30.84.100:/srv/arch -K /home/aeden/out/Image -d /home/aeden/out/tegra194-p2972-0000.dtb jetson-xavier eth0

Is that why I got down voted? This thing is header-only, I'm guessing it doesn't need rtti or have a big footprint.

Nobody knows about BOOST_SCOPE_DEFER?

#include <boost/scope/defer.hpp>

BOOST_SCOPE_DEFER [&] {

    close(fd);                                                                    

Implementation here: https://github.com/boostorg/scope/blob/develop/include/boost...

Fantastic links. They should be at the top of this thread. This stuff looks really impressive to me. I'm not an expert.

I take it that it is implicitly assumed that code running on the server (which I cannot spot the source for) doesn't need to be available, to be trusted? (That there's no way you could come up with an attack through cryptanalysis, involving what the server does, since the security of the data coming from the client is all that matters?)

How did they do it? The idea for homomorphic encryption has been around a long time, but as far as I am aware the time+space requirements have found to be tremendous, thus rendering any serious implementation of it impractible.

If they managed to do it, they should open-source the code. If they made a research breakthrough, they should publish. Doing either of those things would give me the peace of mind that I need.

I went to ghostty.org and spent a long time staring at that animated ghost, and thought of clippy. Except this guy seems to have wider range of emotions.

Anyways, I eventually learned this was about a terminal emulator (which is awesome), but the ghost on the front page really inspired my imagination. I think it would be a good thing to have some kind of companion like that, when it's me, by myself, constantly surrounded by terminals all day. Is the choice of having the ghost be rendered in a text-mode terminal important? I think it is for me.

What I like about foot is the heuristics governing text selection with the mouse. I find that more often than not, if I double click with the mouse on some text, what it ends up selecting is just the part I need.

Yeah, totally. I find LLMs are very useful for doing stuff with the preprocessor, too. ChatGPT taught me how to use boost preprocessor (BOOST_PP_FOR_EACH_PRODUCT).

Still though, I want to see MyMapType::value_type in compiler errors rather than... Well, you know. It's going to contain the type of the key, the type of the value, the type of the allocator, just when all you want to really know is that it's a pair<key, value>, which I think most people know of as My map type::value_type.

For the love of God when will c++ compilers finally be able to output template errors that aren't completely expanded and are written in terms of the user's typedefs? Most of the time I spend parsing template errors with boost is just to figure out what the hell is being complained about.

Before #define ing MY_MACRO, do

#ifdef MY_MACRO

#error

#endif

edit: and #undef MY_MACRO after done using it, ideally.

Many people dismiss mathematics because they aren't interested in it. I definitely wasn't interested in doing dozens and dozens of error-prone problem sets that mainly boiled down to performing arithmetic. I don't need to do that.

My number theory professor was a brilliant mind, someone who had spent lots of time at the Institute for Advanced Study, and he absolutely sucked at adding/subtracting/multiplying numbers. And that was something he freely admitted. It wasn't important to his work, and it isn't important to mine.

In my high school we were basically only instructed to get good at applied math. Calculus. Which more often than not was simply "plugging it in". Most of that work is trivially automatible through Mathematica. When I reached a university, I took number theory and abstract algebra and it blew my mind that math was actually so beautiful in a way that defied explanation. When I took real analysis I finally saw the side of calculus that didn't seem like a waste of time.

One day, I went back to my high school and spoke to my computer science mentor back then [1]. I passionately asked him why we were never exposed to group theory. The answer, he said, was the SAT. None of that stuff is on the SAT, so it can't be justified teaching.

[1] The great Andrew Merrill

Then what is proton written in? C++?

My model for LDD in my head was, "run the app up until the entry point of the executable, print the loaded DSOs, and exit() before ever starting the exe." That'd get you potentially more libraries than if you just statically examine the needed libraries recursively.

I guess I wasn't sure that DT_NEEDED entries covered everything. Sometimes you have stuff that happens in DT_INIT constructors.

Disentangling who loads what without actually running the app, i.e. allowing a sequence of dlopen() calls to succeed, seems impossible to accomplish in the presence of binary code which cannot be effectively scrutinized.

Yes, there are some wrinkles in upgrading packages on Arch, like you said. I've had to manually install archlinux-keyring with pacman. Ive had to manually upgrade yay because a shared library it is dynamically linked to was upgraded. I've had to rm -rf my gpg cache due before.

But my post was primarily focusing on the experience of building / modifying packages. To elaborate just a bit more as an example, the Debian docs claim one can use this environment variable to control certain things when building a package.

DEB_BUILD_OPTIONS='nostrip noopt debug'

What they don't mention, is that these environment variable values are only enabled on a case-by-case basis for every package. Which means, you can't just expect to be able to easily rebuild an arbitrary package without cleaning first, i.e. doing an incremental build. You have to look at debian/rules, which is highly unstructured (unlike PKGBUILD), uses tons of DEB_ makefile variables which I have no understanding of.

I always have such a difficult time messing with packages on debian. On arch, there is a single PKGBUILD file, and it's basically the simplest thing anyone could think of which makes it bliss to work with. On the other hand, debian/rules is a complete mess, apt-get update is notoriously slow, and I have not had good experiences with dpkg-buildpackage compared to makepkg.

Are delay slots unique to mips? They're a pretty significant aspect (complication) that I don't see anywhere else.

Also, the gp register- don't know of any other arch where you need to set something like that up to access global variables. It's another layer of indirection which makes the assembly code harder to read (especially PIC code that works off of the value of the t9 register)

Yeah and key here is that there's nothing to stop you from cloning the repo for a package, checking out an older revision, and running makepkg (granted, it's not guaranteed to work but...)

The GLIBC_TUNABLES can be used to "choose" between different versions of e.g. memcpy at runtime. This can be really useful for debugging, if you want to allow/disallow AVX extensions, for example (even if your CPU supports them). This is what I use on x86_64 to make life easier for my "static" version of qemu usermode:

  GLIBC_TUNABLES=glibc.cpu.hwcaps=
              -AVX
              -AVX2
              -AVX_Usable
              -AVX2_Usable
              -AVX512F_Usable
              -SSE4_1
              -SSE4_2
              -SSSE3
              -Fast_Unaligned_Load
              -ERMS
              -AVX_Fast_Unaligned_Load

In drawing comparison to the "Angry Young Men" [1] of British playwrights, did this piece of writing establish a new wave of "Angry Young Hackers"?

[1] https://en.wikipedia.org/wiki/Angry_young_men

Personally I regard llvm-readobj and llvm-objdump as the state of the art. They are very well written.

I'm surprised no one has mentioned qpdf.

https://qpdf.readthedocs.io/en/stable/overview.html

It turns a PDF (typically everything in it is compressed binary blobs) into a mixed binary/ASCII file (which itself is a PDF) that can be edited with vim.

I have an Intel GPU (HD Graphics 520) and gamescope doesn't work for me under arch Linux :( https://github.com/ValveSoftware/gamescope/issues/356

IFunc relocations are how glibc dynamically chooses the best memcpy routine to use at runtime based on the CPU.

see https://github.com/bminor/glibc/blob/glibc-2.31/sysdeps/x86_...

Why not use the linux kernel's statically-sized hashtable code?

https://pastebin.ubuntu.com/p/rvT9yKTqnP/