HN user

sebcat

1,236 karma

Mowgli could not help laughing when the Bandar-log began, twenty at a time, to tell him how great and wise and strong and gentle they were, and how foolish he was to wish to leave them. "We are great. We are free. We are wonderful. We are the most wonderful people in all the jungle! We all say so, and so it must be true," they shouted. -- Kaa's Hunting

Posts15
Comments401
View on HN

It's an easy test though and it can be an SMD component and some PUR-coated magnet wire or 30 awg single stranded kynar hookup wire.

Use a small amount of glue from a hot glue gun to fixate it when done, or epoxy if that's your thing. Avoid cyanoacrylate. Not always needed but I imagine a drone moves around alot.

Bodge wiring is a good skill to acquire - PCBs will not always be perfect. Maybe practice on something else first?

Not using MOSFETs would make it faster, in theory.

My understanding is that the MOS 6502 was MOS, so MOSFET. Not using MOSFETs would make it less of a replica.

Implementing the replica in an integrated circuit instead of discrete transistors would lower capacitance.

The delay time is a consequence of the capacitance.

2200 meter is LF (30-300kHz). Used mainly with huge coils and low power (1W EIRP). then there's VLF (3-30kHz). Then there's ULF (300Hz-3kHz) Then there's ELF (below 300 Hz), used by the stations in question. To put things into perspective.

Speaking of VLF, SAQ will broadcast on 17.2 kHz on July 2nd. You can pick it up with a soundcard directly (not using a DVB-T chip) depending on your location and use of antenna.

My experience is that it's hard to get right, messes with crop rotation and lower yield.

I've had beans overtaking the maize and I've had squash overtaking the beans.

YMMV.

From the Reddit thread the article is based on, OP says:

I want to run an unmodified QMK firmware so I can keep up with updates without having to continually merge my changes into HEAD, and in my research with IO expanders I would have to rewrite the matrix scanning code.

It wouldn't cause the problem in itself perhaps, but I find it a bit reductive to look at the type in isolation like that. Sometime, somewhere, someone will call std::vector<T,Allocator>::data on that vector and use the resulting pointer as the src argument to memcpy (or some other function), and someone else will make a change that causes an overflow of the dst buffer. Shit happens and code written in modern C++ also has bugs and some of those bugs have security implications.

https://exiftool.org/ancient_history.html

    Sept. 26, 2008 - Version 7.44
           - Added read support for DjVu images
There were probably enough systems running perl 5.6.2 around 2008 to cause bug reports, or the code was migrated from an older piece of code and added to ExifTool.

It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.

I did this a while ago. the .iso.xz came in at 22.1 MB and the .iso at ~80MB.

That's for a ro image with tmpmfs and varmfs[0], a minimal kernel, base and the packages nginx-lite, jansson, re2, curl, acme.sh and some services.

The system boots from an ISO into running nginx and hosting a basic network scanner[1] at a VPS provider.

I basically built from source with a custom SRCCONF[2], KERNCONF[3] and some other cleanup[4].

There may be easier ways to do it but it worked out pretty well for me.

[0] https://www.freebsd.org/cgi/man.cgi?rc.conf(5) [1] https://disco1.sajber.se/ [2] https://github.com/sebcat/yans/blob/master/tools/freebsd/vm/... [3] https://github.com/sebcat/yans/blob/master/tools/freebsd/vm/... [4] https://github.com/sebcat/yans/blob/master/tools/freebsd/vm/...

Target the high-end? There might be a demand for a device with an e-ink esthetic which takes care of, I don't know, planning the days of rich people? An actual need instead of a manufactured want? Or maybe the lower power consumption of an e-ink display can make it useful in other areas not yet identified instead of consumer products?

Apart from Linux hw support for things at work, I implemented a fairly simple pseudo-device for establishing TCP connections from a process in capability mode on FreeBSD. The device driver has support for a denylist to disallow connections to specific IP ranges. It has multiple syscalls wrapped into one ioctl, and sockets opened from the device always had TCP_NODELAY, O_CLOEXEC and SOCK_NONBLOCK set. Worked pretty well for its intended use case.

https://github.com/sebcat/yans/blob/master/drivers/freebsd/t... https://github.com/sebcat/yans/blob/master/drivers/freebsd/t...