isopede

I've been reflecting a bit on how nature of the internet has changed, and how niche communities that I used to rely on all had specialty forums, mailing lists, etc, with history often stretching back years.

It seems like more and more of these old-school discussion forums are disappearing, and their modern equivalents (discord? subreddits?) just don't seem to have the same feel. DPReview is probably the most recent example, but I occasionally I will still visit specialty forums like eevblog.com for EE, or VW forums for my car. It's hard to imagine finding the same sort of expertise and years-long knowledge base on current discussion platforms.

Where do we go next? What happens when these communities are lost? Where are we to go if, for example, HN were to disappear?

Can somebody explain to me how banning TikTok is not obviously unconstitutional purely on first amendment grounds?

What do you mean by "stop accepting it?"

All of us rely on millions of lines of code that we have not personally audited every single day. Have you audited every framework you use? Your kernel? Drivers? Your compiler? Your CPU microcode? Your bootrom? The firmware in every gizmo you own?

If "Reflections on Trusting Trust" has taught us anything, it's turtles all the way down. At some point, you have to either trust something, or abandon all hope and trust nothing.

Among others, regulatory reasons can mean Jira is not an option (medical, financial, export controls etc). They removed their self-hosted version a while ago, and their "data center" version is a $42,000 _minimum_.

A few of my recent systems have come with a built-in combo BMC on the motherboard NICs. I haven't seen this before, is it a new trend? I'm imagining they put in a switch in there with the NICs? How does this even work?

I'm doing a few timing sensitive projects involving hardware timestamping in the NICs. Does this mess with say timing variability? I've disabled the BMCs out of paranoia but I don't know the topology inside.

There already has been. The relevant case law is LLC v ReDigi:

https://en.wikipedia.org/wiki/Capitol_Records,_LLC_v._ReDigi....

> On March 30, 2013, Judge Richard J. Sullivan ruled in favor of Capitol Records, explaining that the transfer of digital data from one storage medium to another constituted a violation of copyright, because the copy was ultimately an unauthorized reproduction, and therefore outside of the protection of the first-sale doctrine

While Google may indeed have something internally that competes with ChatGPT, I can't use it. I'm sure that lambda and Meena are cool, but where is it?

So what if Deepmind can now conquer grandmaster-level Settlers of Catan or Chutes and Ladders? None of that impressive work is available to me.

For all their technological prowess, Google fails at actually releasing and maintaining useful products.

I am currently working on a "multiple instrument" setup acquisition with a GPS PPS and a standard reference clock distributed to multiple machines. It is exactly as you said, each instrument has a free-running incremental counter that is reset on every PPS.

If I want to do long delta-t calculations, what is the correct strategy to correlate these acquisition runs to wall-clock time?

Do I record the start time as given by the (PTP disciplined) system clock clock_gettime(), then schedule an acquisition to start at the next PPS/sync? How does one ensure that the recorded "start time" is actually the correct time?

If for example I would like to start acquiring at t=0, at t=-1 I would record the current UTC time (call it system_time), schedule an acquisition to start on the next sync/PPS, and then record the start time as system_time + 1. It seems to me that this would fail if a leap second were inserted at t=1.

Is it perhaps better to do my calculations in CLOCK_TAI, add one second, and then convert back to UTC?

Or, just record everything in TAI?

Everything I know about Brian Eno has come from the New York Times crossword.

I believe one method is to dab the chin rest with a drop of perfume to mask the scent of the violin.

Another way of making it "slower" is to require more memory to compute your algorithms. The idea being that lots of memory is expensive no matter how clever you are with the computation.

This is not true.

Automotive radar are in the ~80ghz range, giving it a wavelength on the order of about 4mm. Car radar can definitely see through rain and snow. All radars receive a range of reflections from many objects, rain included, but the return off of rain is nothing compared to the return off of a solid object. The filtering then becomes choosing the peak amplitudes of the radar return signal. Rain will manifest itself as a smearing of the signal and lowering the peak a little bit, but usually much less than a solid object.

Optical and lidar work miserably through rain/fog, with wavelengths in the ~1000nm range, but have much higher resolution.

Any real self-driving solution in the near to medium future is going to involve sensor fusion of as many sensors the car manufacturers can afford and cram in. This means cameras, ultrasound, lidar, radar, etc. Anybody telling you that there is only one true sensor to rule them all is either selling you something or ignorant of the state of the industry

When does this patch land? I was hoping to see the original in all its glory, but don't have time until later this week...

What would be an appropriate replacement for embedded systems? I've looked at the "tiny" versions of protobuf (nanopb, etc), but haven't tried them yet.

Are protobuf competitors (flatbuffers, capnproto) appropriate for small embedded systems (microntrollers, mostly <64K RAM).

Thanks.

I really want to wanted to like Phabricator, but every interaction with arcanist just feels like hitting the "I'm feeling lucky" button. It completely violates the principle of least surprise. To me, at least.

My new team is using Github. Can Github be wrangled to enforce a rebase-on-merge workflow with PRs? I am committed to keeping the "one commit per idea" mantra, but I don't see any way in Github to enforce "no-merge commits."

Does Github keep track of comments across PRs if they are rebased? I don't want to see extra commits on top of PRs that consist of things like "address reviewer A's comments," but I do want the comments tracked on Github. Is this possible?

Can you describe your stacked workflow with phabricator? I have tried to impose the LKML/straight-line-rebase workflow on my teams when I can, but problems with Phabricator _always_ crop up, and it's difficult to onboard people.

The default phabricator workflow really likes to squash many commits into a single diff. How do you go about preparing a "stack" of changes, prepare one diff for each git commit, and then apply changes on top of each one as review comments come in?

I've ghetto-rigged my own scripts to generate stacked diffs, checking out a new branch for each one, but it's fragile, and not really suitable for sharing with all new team members.

I have not found a magic arcanist incantation to generate a changelist based on multiple commits.

Perforce is great for binaries, but really kind of a substandard experience for code, at least compared to hg/git.

I also tried Git LFS and it is a hot mess.

I think they could go a long way to fixing this by building a textual representation of blueprints. I can see art assets being unmergeable, but as far as I can tell there's no good reason why nodes, the netlist of connections, and their parameters couldn't be stored in text.

At least this would allow diff, merge, and code review with standard tools.

I have been getting into Unreal the last few months and had the opposite experience.

I found the visual programming language frustrating to use and reason about. While I loved the discoverability of working with blueprints (it is easy to find new nodes), I found that actually working on game logic quickly devolved into an unmaintainable mess of literally, spaghetti code. It was great for prototyping, but horrible at actually building something maintainable and understandable. Reading other people's blueprint setup is even worse.

I found the workflow even more frustrating. Blueprints are stored as uasset binaries, and as such make traditional version control impossible. Changing a single default parameter in a blueprint rewrites the entire file, and can not be diffed, merged, or reviewed, making git/p4 log nearly useless.

I know there is a builtin diff/merge in the editor, but it's pretty limited and I would say it's quite a far cry from what "normal" developers are used to in other parts of the software world.

I have since switched to using mostly C++, and only using blueprints for derived Actors to set up art (meshes, materials, etc). It's definitely slower to set up than using the blueprints. I'm not happy about being back in a place where segfaults can happen; the compile-play-crash-restart cycle is much longer than it should be. I'm not a huge fan of C++, warts and all. In return, however, I can actually read the code, grep it, review it, etc. Do "all the things" you're supposed to do as a good software engineer. I really don't know how the AAA game studios are managing real games with blueprints, I kind of doubt they are.

At least as an experienced software developer but amateur game programmer, I found it much more comfortable to sit down with C++ and learn their API, than it was to perform game logic by dragging around 'foreach' boxes and doing arithmetic by crossing lines.

This exists: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

This is a counter patch which restores the broken PID. The original proposed patch is actually a parody Linux version which bricks FTDI chips.

The real Linux patch which adds support for broken clones is here: https://git.kernel.org/cgit/linux/kernel/git/johan/usb-seria...