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..

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

#include

BOOST_SCOPE_DEFER [&] {

    close(fd);                                                                    

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

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?)

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.

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.

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, which I think most people know of as My map type::value_type.

#ifdef MY_MACRO

#error

#endif

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

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.

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

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.