jcalvinowens

My employers have generally been fine giving me blanket permission to contribute to specific open source projects.

The framing matters: don't say "can I please do some charity work because it makes me feel good".

Say, "can I have your permission to get free rigorous review from experts in my field, and zero out all future maintenance costs for your company by contributing my fixes to the upstream open source project?"

Because that's really how it is. No employer of mine has ever said no to that. It is entirely in their interest for you to do this, you just have to help them see it.

Yet again my plans for a productive morning have been derailed by an excellent new write up from Dmitry :)

That hand rolled DAC for the touchscreen with the eight gpio lines is hilarious.

How fun! I'm glad it was interesting, please feel free to link to it :)

This is fun, thanks for sharing. I have a much more minimalist one for x86 Linux if you want to see what that looks like: https://github.com/jcalvinowens/asmhttpd

I have a self hosting Pi Zero W running Gentoo. It started as a joke, but I kept it because it's actually occasionally useful for testing new kernel releases.

I found a fun bug with it a couple years ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

It is still able to build software faster than it is released. It takes roughly a month to recompile the entire system :D

Arms races suck. I've managed to find a few L7 tricks to catch the residential proxies and serve them an empty 200, but there are obvious trivial workarounds on the other end and if I start talking about them in public they won't last long... I wish I could share :/

Every few weeks I run my nginx access logs through a script that uses the same textual ASN database to tally them up and spit out a summary report. There are many different sources for periodic textual ASN databases you can parse with UNIXy tools.

Yeah, I dont know how anybody stays sane without it. I have a list of over a thousand ASNs I blackhole at this point...

Mine is a daily bash cronjob that fetches a text-based database and uses grep to build an nftables-apply script with all the IPs for the blocked ASNs. I keep meaning to share it, but it's embarrassingly messy I haven't had time to clean it up...

I had to block meta's ASN on my personal cgit server a few weeks ago because they were ignoring robots.txt and torching it. Like hundreds of megabytes of access logs just from them, spread around different network blocks to clearly try and defeat IP based limiting. I couldn't believe it.

If you use the GPIO-based PPS on RT Linux, the kernel will soon get a nice improvement in jitter: https://lore.kernel.org/all/A0383FF7-267A-4D4C-9B74-F80B9908...

I've been testing it and it is noticeably better, but I haven't yet had time to set up an A/B test to get real numbers.

> Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity.

I absolutely 100% agree with this and I'm glad to see somebody saying it. Any system that is one LPE away from being compromised is already insecure.

Never throw anything away. I'm constantly amazed how often even very trivial little programs end up being useful again many years later.

>> [...] and thread 2’s time may be earlier than thread 1’s

> If it does plain RDTSC, it may not be fine.

I'm a little surprised how easily it happens with plain rdtsc on my hardware: https://gist.github.com/jcalvinowens/4c0c25e753f8ce2d0a6ca48...

    # time ./a.out 
    a.out: local=4692633034088164 < remote=4692633034088165
    real    0m0.025s

> Threads have gotten so fast that paying the async function coloring price makes very little sense for most software.

I agree with this 100%.

If you're getting paid to bin pack jobs that do lots of concurrent I/O into a server infrastructure, then yes, building these complex async "machines" and forcing everyone to do the extra labor to use them is necessary to avoid a lot of waste.

But for everyone else, it's a huge waste of time. Even low end modern embedded Linux systems are capable of running thousands of threads.

Synchronous code is always simpler to write, easier to reason about, more straightforward to test, and faster to debug. Nobody should ever reach for async by default.

I doubt it too, but I was hoping to hear from someone who'd tried it. I don't care about peripherals, even booting it without the storage with a serial getty would be useful for me.

Is anybody running Linux headlessly on the m4 mac minis successfully? I'm seeing them flying around used now at tempting prices...

I also appreciate the 10/100 support. I recently needed it for some old voip equipment, and it was shockingly difficult to find an SFP+ module that worked in my 10G switch and supported 100mbps.

I used to drink a small amount of blisteringly strong coffee in the morning and after lunch, but nowadays I drink a massive amount of relatively weak coffee throughout the entire day. Weaker than you'd ever get from a shop or in an office.

That's been a big win for me: I feel like I get to enjoy the coffee more, and it eliminated the negative effects for me.

I no longer feel like I suffer when I don't have it. I miss it, the way I miss the sunlight in my office on a cloudy morning, but it's strictly a positive for me when it's around. I only get headaches if I go from 100 to 0, even one day of reduced intake is enough to avoid it for me.

When I'm exhausted and going to bed, I'll go fill the coffee machine, and catch myself thinking "oh boy, it's going to feel so great to wake up at 6am and drink this". Then I shake my head at myself and laugh and how absurd that sounds :D

Coffee is above running hot water in my hierarchy of needs. Seriously. If I were forced to choose between coffee and alcohol for the rest of my life, I'd choose coffee in a heartbeat.

Honestly, my recent experience with this was really positive: the doctor actually said the technical stuff out loud to me for the first time in my life, in a way I could easily ask polite questions about and discuss with them.

In my case it was something very not sensitive, removing a benign tumor in a finger, which I have no problem telling the whole world about (I was awake for the surgery and got to watch, it was a incredibly fascinating experience that I want to write more about some day).

But I can imagine it would feel much more invasive if the subject were more sensitive.

If you just want to see patterns, and don't actually need to see the values, you can go a step further and simply visualize the data as a bitmap, e.g.

    dd if=/dev/urandom bs=$[256*256] count=1 | display -size 256x256 -depth 8 GRAY:-

You can do the same thing with audio, which makes different sorts of patterns obvious, e.g.

    dd if=/dev/urandom bs=$[256*256] count=1 | aplay -c 1

The experience I'm describing was two weeks ago.

Yes, what we see coming out of the bottom of funnel is now is a little better. But it's sort of like reading day trading blogs: nobody shares their negative results, which in my direct experience are so bad they almost negate any investigative benefit. I also think part of this is that a small set of very prolific spammers were sufficiently discouraged to stop.

My experience with these tools is that they generate absolutely enormous amounts of insidiously wrong false positives, and it actually takes a decent amount of skill to work through the 99% which is garbage with any velocity.

Of course some people don't do that, and send all the reports anyway... and then scream from the hilltops about how incredible LLMs are when by sheer luck one happens to be right. Not only is that blatant p-hacking, it's incredibly antisocial.

It's disingenuous marketing speak to say LLMs are "finding" any security holes at all: they find a thousand hypotheticals of which one or two might be real. A broken clock is right twice a day.

> I generally believe that 256-bit “security levels” are somewhere between a comfort blanket and numerology [...] AES-256 was unfortunately defined to perform more rounds than AES-128, making it needlessly slower.

Obviously if you benchmark it in RAM you'll see it... but with LUKS disk encryption, for example, disk throughput is completely unaffected by the key size on my newer machines with AES-NI.

In cases like that, it seems silly to me to use the smaller keysize: why would I sacrifice even a tenuous theoretical security benefit for absolutely nothing in return? But granted, the larger keysize will have a measurable cost in most applications, FDE is a rarer case.

Yeah, I had the same question. But I'd guess they probably disable IA32 completely.

That could never work, my entire ISP is a /32

The "reputation" concept has to be applied to network blocks in IPv6, because of privacy addresses, and they very clearly aren't doing that for whatever reason. I get at least one captcha a day from a stock Android phone that's been connecting from the same damn /64 for almost a whole year.

For releases! But have a flag to disable it: don't make people edit -Werror out while hacking, that's really annoying.

This could make real sense for ssh host keys, since they need to be used without presence and they're generally tied to the lifetime of the machine anyway.

I saw a write up where someone successfully got sshd to use a host key from a fido2 yubikey without touch, but I can't find it...

As far as "TPM vs HSM", it is soooo much simpler to make a key pair with a fido2 hardware key:

  ssh-keygen -t ed25519-sk -O resident -O verify-required -C "your_email@example.com"

You can get them for <$30.

The "party trick" is more general than just xor, for example:

    void swap(unsigned* a, unsigned* b)
    {
        *a = *a + *b;
        *b = *a - *b;
        *a = *a - *b;
    }

GCC still sees through it with restrict: https://godbolt.org/z/8n3bGha3e

I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.