mafuyu

This tool looks like "submodules, but lighter", while repo is "submodules, but heavier". Looks to me like the motivation is for dependencies that are not hard enough to justify a submodule.

Repo seriously sucks to use, but I also can't imagine many tools living up to AOSP-type workloads without being specifically designed for it. My gripe with repo is that it's really hard to pin the entire repo state if you have a bunch of prototype patches across multiple subrepos. I usually end up having to modify the XML directly.

Not to defend C strings too hard, but it does make some sort of sense, IMO. You have to manage all your buffers manually in C, whether they contain a string or not. If you store a string of length 5 in a 10-byte buffer, you still need to manage the 10-byte buffer. Raw pointers kept things very flexible and lightweight when C was created.

Nowadays, things like C++ string_view's and Rust str slices handle this for you automatically, but those came around much later and require more sophistication at compile time.

I've worked on embedded RTOS projects where we had our own strlcpy implementation - it's fine. Well, I mean, all the str functions suck because C strings, but that's exactly why sticking to a good shared set of idioms and staying organized is so important. And in C, that means manually tagging buffers with their length, no getting around that. Given that, strlcpy is less bug-prone than strncpy, simply due to requiring less lines of code to use correctly per invocation.

I think a lot of the confusion in the C string discourse comes from people thinking they should rely on the NULL termination byte for string length. You really shouldn't, and if you have to do it, you need to be extra careful to check all your assertions that it will be properly terminated. Just carry around the length, and bundle it with the pointer in a struct to pass it around when it makes sense. Not the most ergonomic, but it's C, what can ya do.

Yeah, at the end of the day, you're probably going to advertise with some sort of unique short name (so humans know what to pick in the a connect/pairing menu), and have at least one Service UUID (even if you only expose the juicy stuff after bonding.) But that still pushes it back up to a software policy concern, and it's up to the developers to make the appropriate privacy/security tradeoffs. The only real way around this is to do discovery out-of-band via NFC or QR codes or something.

The other detail worth mentioning is that generic service advertisements and beacons will have different behaviors and payloads, since they have different goals.

With the former, the device is advertising because it's disconnected and needs to be discovered. Service discovery necessarily means you're sending out some sort of information about what you are. If it only expects to be connected to one device (ie. the phone), it's going to turn off advertising when connected to said phone. You technically don't need to advertise the service UUID either once you're bonded, although I don't think would happen much in practice, as it makes recovering from an unbond event harder.

Meanwhile, a beacon is data that is intentionally being broadcast out to the world by an application. The application will probably send out beacons regularly no matter what, since that's usually the point (Find My, COVID tracing, etc.) I would expect companies like Apple to ensure that these advertising packets aren't leaking any identifying information. This is easier to do than the above case, because the goal isn't service discovery, but to intentionally broadcast a piece of (anonymous) info.

tl;dr Beacons are fine, especially in comparison to your headphones or smartwatch loudly announcing itself to the world because it's disconnected

BLE beacons use advertisement packets with a payload, and at the end of the day, are sent actively by an application (like COVID tracing). With MAC address randomization, it's possible to make them anonymous and untrackable at the protocol level. This paper uses data from the physical layer to pull more metadata to track devices, ie. error and drift in its RF frontend. It's not, not a concern, but it's also not data you'd be able to grab with a normal BLE chipset in sniffer mode. You'd likely need an SDR, and that's what they use in the paper. It's an attack that's on a different level of sophistication and cost.

Additionally, I wouldn't worry too much about beacons on their own (at least, in this context). Beacons are just a form of BLE advertisement packet. Your BLE devices need to send out advertisements anyways to let your phone to know they exist and connect to them. I assume this attack works on any advertisement packet (and also data packets to a connected device). Normally, rotating private addresses will mitigate some attacks tracking two devices talking to each other, at the protocol layer. This paper is more just a broader look at what features you can extract at the physical layer with an SDR to identify a specific device or chipset.

> can the gpu render to other display devices as normal?

Yep, it will just result in your driver showing up as another `fb` device. Then, you can configure the kernel fbcon boot parameter to use your display for tty, or launch X configured to use your fb device. This would also let you do fun stuff like run mpv pointed directly at the fb device without running X at all :)

I put my email in my profile, so feel free to message me if you need any pointers.

dmenu and rofi/tofi are pretty popular on Linux, especially with tiling window manager users. I use tofi with sway, and it's blazing fast compared to Spotlight (but Spotlight is searching a lot more things at once). They also take stdin, so you can hook them up to all sorts of things (eg. ssh hosts, clipboard history, password manager entries, etc.)

Awesome! I think the next step for this project would be to implement a proper DRM kernel driver and device tree overlay, instead of copying the framebuffer in userspace.

For reference, take a look at the Beepy display driver module: https://github.com/ardangelo/sharp-drm-driver. It's for a monochrome Sharp memory LCD, but still uses the SPI interface on a RasPi.

Yeah, bus systems suck. People avoid buses because they have unreliable schedules, and dedicated bus lanes are intended to improve that. Putting every rider on a bus into their own dedicated rideshare car isn't really going to improve things, though...

It's exciting to see Waymo and self driving technology in general doing well, but the analysis on the broader implications fell flat for me. Claims about improving commutes or being more effective than mass transit need to be substantiated - there's a ton of stuff out there on traffic engineering, mass transit, and urban planning that can help perform these sorts of analyses.

Some thoughts:

* For the purposes of transit efficiency, self driving cars are very similar to Ubers. They have a low passenger density (being a regular car), and once the passengers disembark, they still take up space on the road with 0 passengers. Better experience and lower costs will basically just induce more demand over more efficient mass transit options. If you imagine everyone at a bus stop ordering an Uber, or have ever seen the flurry of Ubers after a big event, it's clear why self driving isn't really addressing the core issue.

* You can't really make direct cost comparisons to the infrastructure costs of bus lanes or subways like that. Infrastructure is ungodly expensive in the US, yes, but there are very well understood reasons to make dedicated bus lanes and subways: they don't compete with cars on the road. They're high density transit options, so having more reliable service will impact a lot more people (and reduce car congestion on the road!) A rideshare service is wholly unprepared to deal with the transit demands of a larger city, and imagining that we'd replace existing mass transit options with it is silly.

* I don't really understand the point about suburbs. You can already get that experience today by ordering an Uber to and from work. If there's more demand, it's just going to make traffic even worse while promoting more suburban sprawl.

I'm not an expert at all, but my understanding is that Gaussian splatting is essentially a rendering technique. Normally, you'd take actual data, like a set of photos, and optimize some Gaussians against it to arrive at a volumetric representation. In the case of AI-generated splats, it's kinda flipped. Instead of optimizing against a known ground truth, the AI is generating Gaussians to be rendered. The insight of this paper is that we already have great statistical tools for numerically estimating ground truth based on a bunch of Gaussians, so why not just apply those?

Eh... Not buying it. At least not the way they're marketing it. This looks like a group that dreamt up another one of those massively SMP multicore designs and are shopping it around as a coprocessor IP to license. Maybe there's interesting stuff in there, maybe not, but it's not a new idea. Cooking up some massively parallel benchmark and telling journalists it's going to make computers 100x faster is unethical and counterproductive.

The usual speed bumps with these SMP designs show up in the white paper. There's a section on how they can use recompilation to automatically accelerate existing code. There's a rich history of failed attempts at automatic parallelization at compile time. So this section is just an admission that you're going to have to write code specifically for this thing to get anything out of it.

This coprocessor concept looks like it needs to be tightly coupled with the host CPU to work. The upside needs to be massive to justify a vendor integrating with this IP and also overcome the software adoption costs. Especially since they're directly competing with GPGPU...

Also some strange red flags, like the comparison to quantum computing in the FAQ. (Did they feel the need to include this because an investor asked?)

My guess is they've done some interesting core research around memory bottlenecks/latencies in a massively SMP architecture, and picked up investment to attempt to productize it. But the way they're marketing themselves right now doesn't inspire much confidence.

You're not necessarily wrong, but I wouldn't call it alarming in the context of an RTOS. Sometimes you just want to invoke the scheduler and let other stuff run for a while. In an RTOS, yielding or sleeping for a number of ticks has deterministic behavior. If you sleep for a few ticks, come back, and then have to sleep again, it's not the end of the world. Blocking on a concurrency primitive would be better, since you wouldn't get scheduled at all, of course, but sometimes you just don't have what you need hooked up. I'm not surprised to see them in the net stack - there's a lot of layers involved in networking, and network latencies are usually orders of magnitude longer than a scheduler tick.

Yeah, when this press release was making the rounds a few days ago, I tried to dig up more info, and didn’t find much. It seems like they’re aiming to connect terrestrial BT devices to satellites? I just don’t see how it could work.

Maybe the actual tech they’re shooting for is to wrap the BT protocol or modulate it up to blast at satellites? Then you could enable connectivity for existing BT sensor networks and such. They explicitly say that it doesn’t require a hardware retrofit, only firmware, though. I suppose you could hit some sort of harmonic on a 2.4GHz antenna, but that would be very dependent on the frontend and antenna design, and the SNR would probably suck. Something doesn’t add up.

Conceptually, I’m also not really sure if the pitch makes sense. Sure, let’s say you can do firmware patches to BT chipsets, but was that the expensive/hard part? Does the BT protocol and spec make sense in the context of hitting a satellite? It’s clearly not designed for it in terms of latencies, airtime, etc.

Pretty much in-line with my expectations. I ordered one because I thought the design was neat, and I was interested in hacking around and flashing my own stuff onto it. The pricing was clearly at or below cost.

Looking at just the concept (and ignoring execution), I don't really see the point of this thing? The whole thing is a feature that could exist on a smartphone. The dream of an AI agent that you can converse with to replace your smartphone could be compelling, but nowhere close to reality yet. Even then, the big smartphone OS companies are obviously better positioned for this. The smartphone is the hub for all your information, plus they have years of voice assistant, automation, and home IoT integration to build off of.

Humane was silly because it was a smartwatch without any of the proper software support, but Rabbit is essentially doing the same but targeting a smartphone replacement. If you really want to break out and try to dethrone smartphone vendors, you'll have to come up with something more compelling than a worse user interface to a poorly made software platform. That's a software feature you're building.

In some sense, I do think Rabbit had a better approach than Humane, though. Getting a bunch of low-priced "toy" devices into the market that are just a frontend to your server software could get you off the ground. The software needs to exist, though...

I would ask yourself if you enjoy writing software, and consider trying different SWE jobs and areas if you do. To me, it seems like you're struggling because of your workplace conditions. There are many, many SWE jobs out there (all sorts of industries need to write software!), and even SWE is a very broad term. For example, you might hate webdev but end up really enjoying writing database software or mobile apps or whatever else. If on-call and deployments are stressing you out, there is software out there with longer release cycles that doesn't require on-call at all.

The start of your career can be tough, as you don't have much experience, but it's also a good time to explore and try different options. Don't let one bad workplace define your entire career!

That said, it's also totally fine if SWE is just not a good fit for you. There is a lot of process around planning, code reviews, git, etc. that is separate from the act of coding itself. If you want to keep coding, there are plenty of areas and industries that still need to write code. If you want to switch careers but stay tech adjacent, there are some broader options too, like IT and sales engineer.

I'm an electronics guy too (if you count firmware :P), and I've always found the spring contacts on TRS jacks to be hit or miss. It's a big receptacle with lots of room for lint to get into, the plug rotates, and it can experience some big forces on drops or cable tugs.

Most jacks do just fine, but having the springs eventually wear out on some device or another wasn't uncommon for me 6+ years ago. Not having to worry about whether the jack is going to suck or not on a given product suits me just fine. Having it attached to an adapter means I can easily swap it out if it wears.

That said, some of the sibling comments are reporting wear on USB-C receptacles when used while running... The mechanical design of the Apple Lightning connector seems to me like it'd be more durable, since it's tapered and doesn't have that center alignment thing. But maybe the contact springs of Lightning wear out faster as a result? I haven't seen any data on this, just speculating.

I think it varies a lot from product to product, and much of it is the mechanical design of the phone housing, and the durability of the jack they selected. Plus it’s really easy to accidentally put a lot of mechanical strain on it when the cable gets tugged.

MiniUSB was a busted connector design from the start, which is why the industry moved to Micro USB so quickly. Many MiniUSB receptacles in the wild were failing after thousands or even hundreds(!) of insertions.

The industry seems to have settled on USB-C dongles as the solution for wired headphones. They’re a little clunkier, but they do work pretty well, and you get options for the DAC.

Headphone jacks were a major wear item on older smartphones, and waterproofing them is very annoying as well, requiring a ton of adhesives. I had to take the back glass off my old Xperia Z2C three times over its life to replace the headphone jack, and the waterproofing was totally shot after doing so. At the end of the day, I honestly don’t mind the trade off, although I can see how it can be annoying for others.

Sigh, yet another business that takes money in exchange for a service. I'm sick of it. I think this site would be much more compelling if I could pay an annual fee, and then get some money back for each image I want to become an ad-riddled social media-ified mess. That way, I could deposit my life savings and use it to top up my bank account whenever I need some liquid cash.

If you’re interested in this, I’d highly recommend checking out the Hoeg Law channel on YouTube: https://youtube.com/@HoegLaw

He’s done a bunch of analysis on the Microsoft / Activision merger, as well as all the Epic lawsuits.

It’s an interesting shift in Microsoft’s position, but I think they see where the winds are blowing, and most importantly, they’ve set themselves up to not be as impacted by an opening up of store ecosystems.

Windows is obviously huge for gaming, and Game Pass is the way that they’re bridging the gap between the more “open” Windows ecosystem, and Xbox. Microsoft marketed Game Pass heavily, and even with my distaste for subscription-based rental services, I have to admit, it’s a pretty good deal for now.

I’ve seen many of my friends use Game Pass and like it. I think it passes the sniff test for a no-fuss service that has games people actually want to play. I wouldn’t be surprised if Valve treated it as much more of a threat than the Epic Games Store. Nobody I know takes the EGS seriously, but a subscription service could represent a paradigm shift.

Jack Welch is kind of a poor example to reach for, isn’t it? In my view, his financialization of GE was very harmful, so yes, I think he would have helped the world more if he did literally anything else.

From what I remember from school, the extremely rough rule of thumb, specifically for thermal effects on the silicon itself, is that +10C will halve the lifespan of the chip. When you try to push a chip with an OC, the power/perf gets highly nonlinear, so you end up making tradeoffs here. Chip vendors like Intel and AMD do a lot of testing and validation to pick power curves that will meet the warranty specs of the chip, but they do have some wiggle room.

There’s a whole bunch of other failure modes that aren’t captured by the 10C rule. It’s more for estimating chip failure due to things like electromigration. You can observe this if you run a desktop CPU overclocked for many years. I had a 2600k that I had to keep bumping the OC down on, and jt eventually bit the dust after a decade.

Oh wow, you’re absolutely right! I guess I should read my manuals more carefully. :) I’ll have to give that a shot next time.

As a fellow fp enjoyer, I will point out that I believe the fp's CDNG support avoids patent issues by only supporting output to USB drive. RAW video to internal media is where Nikon ran into trouble. It's also a bit of a bummer how terrible the fp's h264 encoder is, but the CDNG makes up for it, I suppose.

Agreed. I elaborated a bit more in a sibling comment about how many keybinds result in opening a pane and focusing it, and it’s just not built for being operated by keyboard. Although you could make the argument that using the mouse just hides all the latency. Scrolling through text buffers is super smooth… but at what cost?

I think this gets at my feelings on latency as well.

Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)

With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.

With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.

(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)

As someone who’s worked on both embedded and Linux-based smartwatch firmware, yeah it’s mostly battery life. The nice part about developing for a lower power microcontroller is that you can basically aim to squeeze as much performance out of the chip as possible, and the power draw will still end up pretty good. On Linux devices, you need to an architecture early on for how you’re not going to blow your power budget immediately. Even stuff like entering/exiting suspend can be problematic in how many Joules it takes.

I understand the types of considerations that may make console developers not bother, but also it is a bit ridiculous on its face when they are selling physical media. But for patch-heavy games like CoD, maybe it’s a lost battle anyways, archival be damned.

But I will push back a little and say that a zsync-like differential update scheme would still be totally feasible. BD read speeds are going to be in the 100s of megabits per second, and the compute for the hash is free (ie. It’s I/O bound). You can parallelize and start downloading blocks before you’re done hashing every block on the disc. It seems likely to me that you’d still end up better off with this scheme if you have slower than gigabit download speeds (which is true for the vast majority of the US). Zsync is fairly coarse and flexible, and essentially looks like BitTorrent between two peers over HTTP if you squint. If you assume the download speed and network reliability is the bottleneck that outweighs things like disc I/O and compute, it essentially degrades gracefully to just downloading the entire update in the case that there are zero matching blocks.

Edit: I should mention that another key aspect of the setup is that there are a small number of printed disc revisions, and a small number of target download (most people will get the same game files for a given region). This means that a CDN cache will quickly find the hot blocks to serve, even without any precomputation of the diff between source and target.

It’s the small latencies that add up for me. I usually use a tmux + nvim setup, but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust), I have a VS Code setup with the nvim plugin that I’ve spent way too many hours tweaking hot keys and things.

Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition between panes and such. Even just scrolling with nvim keybinds feels a bit off. My key repeat rate is fairly high, and I’ll hold down ^D to skim through a source file. VSCode’s renderer struggles to keep up smoothly sometimes.

This is all nitpicky stuff, not enough for me to swear off VSCode or anything. But it’s just annoying enough that every once in a while I end up in some rabbit hole of VSCode internals and css tweaks, instead of doing actual work. Most coding does not require a ton of bouncing around, but it does feel very liberating to have confidence in my inputs as I navigate around.