mafuyu

I mean, zsync? Performing simple hashes of blocks of data isn’t exactly hard for the console. On the CDN side, just add a caching layer for the resulting chunks and it should sort itself out, since there are only so many variants of the source disc. It won’t get you the best compression ratios, but it’s flexible. We were considering this for firmware updates of an IoT product. It’s not like differential updates are unheard of.

It's very much doable. You see the big vendors upstream proactively, and they have whole teams supporting upstreaming efforts. But chip bring-up and driver support can be messy affairs. It's not just a matter of a driver working or not- hardware bugs or weird undocumented behavior show up all the time. If customers aren't exercising some feature of the chip, bugs can and will go undetected in that module.

The datasheet only gets you so far, especially for undocumented hardware quirks, and the vendor is in a much better place to understand what's happening and fix them. It's an active process of reporting bugs, investigating them, and getting fixes merged upstream into the vendor's BSP, at the very least. This requires active maintenance, which means engineers on the vendor side. That's where the support contracts kick in.

Upstreaming to Linux on top of all that means that you actually need to support and validate the set of features your chip claims to support. That means more thorough test and validation, code that meets the standards of the kernel, and more engineers to actively maintain the code. Not to mention the language barrier for Chinese chip vendors.

Of course, any upstreaming efforts are great and I think things are trending in a good direction. Just pointing out that there are reasons things are the way they are. Fabbing a chip that isn't completely buggy and people want to buy is already a small miracle- better software support can always wait until the chip becomes a hit.

This is a common story in ARM / embedded linux. SoC vendors’ main focus is to make the chip and give it enough BSP support for customers to buy it and build their products around it. The bare minimum for this is typically a set of hacky kernel patches targeting a giver kernel version.

The customer then needs to figure out what they want to do: Take the kernel blob as-is? Get the vendor’s kernel source and try and modify it for their specific needs? Rebase it to a newer kernel? The customer typically wants to just get enough support to ship their product; they’re not in the business of maintaining some other company’s kernel patches. They’ll do it if they have to, but the engineers will grumble about it the entire time.

Thus, getting support landed into Linux upstream is primarily the task of the chip vendor. There’s a good business case for it, as better and widely available software support will help sell the chip. But it’s also incredibly expensive to write all that kernel code and take it through the process of upstreaming. A lot of this stuff won’t meet the standards of the Linux kernel without lots of work.

The ARM SBC market flips this, where you have a bunch of enthusiasts, and then a smaller market of businesses wanting to use them in their products. That can provide enough momentum for a community-driven upstreaming effort.

The first couple AW gens didn’t really have much of a fitness angle, though. The hardware and software for health tracking was very lacking. It was only later on that they pivoted hard on fitness and did a big marketing push with the “three rings”.

Years ago, I had the lovely opportunity to take the course associated with the student manual at Harvard Extension, taught by the author, Tom Hayes. I was a little high school brat, so Tom probably does not have fond memories of me, but I loved that course, and it set me on the path to becoming an embedded engineer. If you're in the Boston area, consider taking the course via Harvard Extension!

A list of unactionable aphorisms without context?

Bigme has been a player in the niche eink tablet market for a while now, so it's likely real, or at least not a complete scam. The fake marketing videos in the Kickstarter are atrocious, though. I would say Dasung and Onyx Mira are the popular brands for eink monitors. If you only want greyscale, those two have decent options available today. It seems like this larger color eink panel just became available, which is why you see both Dasung and Bigme building products around it now.

Seriously? The grinder is the most important part, in my experience. When I first got into aeropress and pourovers, I was frustrated for years with bland and inconsistent brews. It was only after I upgraded to a decent burr grinder that everything fell into place. It’s just impossible to tweak anything else without first starting with a good grinder. I make adjustments of a few micron at a time with my grinder, and the difference is significant for both espresso and pour over. It’s much rarer that I make adjustments in water salts, brew temp, and brew method.

This was my experience as well. On X11 + i3 (with no DE), latency and screen tearing was always an issue I had to fiddle with. Things came to a head when my 2021-release work Thinkpad started tearing driving an external 4K monitor over Thunderbolt. I switched over to Wayland + sway, and it was a night and day difference. Significantly better latency and no tearing, even driving two 4K displays with an Intel iGPU!

The laptop docking story is also significantly better. Waylands libinput lets me assign mouse accel and keyboard repeat rates/rebinds to specific devices, and they always get applied on hotswap, no custom udev rules needed. For audio, Pipewire is sensible and Just Works. Kanshi works sensibly in a way that I was never able to convince dockd to.

Wayland is what brought me from “I like Linux for a work/coding environment, but it’s too fiddly for a daily driver” to finally consistently using Linux in a personal and professional capacity.

You're not imagining it! The ads slow down webOS a lot, and blocking them with pi-hole made my TV much more usable. I highly recommend setting up pi-hole or similar, and blocking all the LG domains it tries to hit.

I commented about it a while back here: https://news.ycombinator.com/item?id=34374725

I should add my personal opinion, too. FPGAs and comp arch can be fun, but are largely academic, IMO. Unless it's your _thing_, it just provides you with lots of background knowledge when writing OS and systems level code. Messing around at the systems/OS/embedded level will be more fulfilling and scratch the same itches.

Hi, embedded developer here. Learning electronics and lower-level computing concepts is very fun, and I'll always encourage it. But I also don't think you need to feel particularly anxious about it. For some perspective, web stuff scares me, and while I have some passing knowledge of things like CSS, React, SQL databases, Docker, etc., I'd be hard pressed to actually use those technologies to create and stand up a modern web service without lots of research and learning.

"How a computer works" is very broad, and covers a lot of different disciplines. Like everything else in computing, it's layers of abstraction, and there's a lot of depth you can go into at any level. What you're describing is basically an ECE undergraduate curriculum, but it's very possible to get a "tour" of various layers in less time than that without going to school for it.

There's a lot of different ways to approach learning, and the bottom-to-top tourist approach is certainly one way to do it. I personally would not recommend it, as you're going to run into lots of different concepts that will take time to digest, and some of the tooling will be rather opaque or foreign, without a mentor to guide you. Another approach would be top-to-bottom, where you do some C systems and kernel hacking and work your way down from there. If you the art of programming and Computer Science, that might be a better fit, but there's also lots of arcane stuff in Linux and x86 that can be demotivating. The approach I advocate is usually the "maker" one, where you hang out in embedded systems land, and come up with projects you want to make. The benefit of embedded projects is that your projects will be physical things that interact with the real world (which may or may not be actually useful). That lets you explore a breadth of topics as needed, but is a bit adjacent to your goal of "knowing how a computer works".

Re: geohotz's curriculum, have others actually done his course? The curriculum looks interesting, but laser focused on bringing up a CPU in Verilog and bootstrapping the OS in C. I'm not sure how easy the course would be without at least some Verilog and systems programming background. 12 weeks seems very aggressive, and you're gonna end up missing concepts if you try to do it at that pace. The course I usually see recommended is nand2tetris, but I haven't tried it myself.

For foundational curriculum, I would probably recommend:

* The CSAPP Book (https://csapp.cs.cmu.edu/) - The introductory systems programming book/course. The labs are really good; do them! You could probably spend a year just with this course and come away satisfied. It'll have you interfacing with computers in C, learning about how cache works, writing your own malloc, doing some networking code, etc.

* Circuit Design - Optional, but some electronics knowledge doesn't hurt, depending on how far down the stack you want to go. Don't need to go into the fancy stuff, but should at least know enough of the basics to understand how transistors work, and how they can be used to form gates.

* Digital Design / FPGA stuff - I don't have a good rec for this. Nand2Tetris? There are some interesting projects out there that make FPGAs more accessible, like fomu and the reverse engineered open lattice toolchains.

* Computer Architecture by Hennessy & Patterson - Guides you through the concepts of a CPU, and has you writing your own MIPS CPU in Verilog. ARM is cool and all, but for a toy CPU, MIPS is a little more manageable, IMO. If you try to go straight to comp arch without some base level of digital design/FPGA/Verilog experience, you will probably have a bad time or end up with some gaps in your knowledge.

This is such a tired argument nowadays. Yes, at some point it is about the directors style and artistic vision. Yes, film _still_ has some technical advantages over digital for cine, especially if the director is shooting at a larger format size. Yes, good color graders can take footage from an ARRI and make it look like a certain film stock. No, it’s not that easy to do. Yes, you lose effective resolution taking a bayer filtered image and then converting it to monochrome with the appropriate spectral sensitivity. Yes, ARRIs have a lot of dynamic range now, but they need to leave much more headroom with digi to recover the highlights. Yes, grain is pleasing, and is an important part of the way the image is perceived (see: Arris various new looks in their new camera, that directly modify how the sensor is configured for different grain styles)

The main advantage of digital in cine is that you can shoot and reshoot without dealing with the cost and logistics of film. But it’s Nolan’s summer blockbuster in IMAX format, I think they’ll be alright.

VCs want to feel good about investing in innovative and exciting startups that will give them massive returns, and the free market responds with founders who meet their emotional needs by selling personalities that are quirked up and coked out with just a hint of sociopathy. Truly a virtuous cycle.

Open-source hardware licensing is not as straightforward as software, and funding isn't really figured out yet either. Hardware has significant costs to develop, manufacture, and sell, and many projects are niche or passion projects that can't compete with mass manufactured clones. Legal obligations of the licensing aside, the understanding is that the primary way to support the creator is to buy directly from them. Prusa has gotten pretty big and it looks like they want to make decisions about whether they've outgrown that model or not.

With software, it costs nothing to just git clone and build for your personal use (which also presents its own funding challenges). For hardware, there's gonna be a chunk of people who just want the product/functionality via clones, and you need to be careful to keep the community/project to grow sustainably. IMO, it should be along-side and not in spite of those clones, but you can see the frustration.

For my mono font, I converted the Atkinson Hyperlegible[0] font into mono, and have been using it as my terminal and editor font for over a year now. It's pretty janky, but it's surprisingly lasted longer than many of the other fonts I've tried over the years.

If you want to try it: https://github.com/Hylian/atkinson-monolegible

[0]: https://brailleinstitute.org/freefont

I think as a direct replacement for internet search, or even general knowledge queries, I definitely agree with you. When it does work though, it's hands-down a better experience. I imagine the 80/20 problem of making it work for the long tail of difficult queries that people will throw at it that will be the hard part. You can't just have a bot spewing out blatantly incorrect data without sourcing half the time. I think it's a coin flip whether those issues will be resolved anytime soon.

Where I do see it being handy is with mundane tasks or those "tip of my tongue" queries. I was doing some tedious mapping of enums to other enums today, and that's one of those problems where you can script it out in vim/sed, but then need to spend a while double checking it against the spec anyways. I'd love to ask a bot to do that for me. Similarly, the easy stuff like "how do I do [common git operation] again?", it seems to do great on, since there are canonical answers to that stuff.

I've been generally uninterested in the ChatGPT craze, but I did check out perplexity.ai when it popped up on HN a few days ago. It did seem genuinely useful for these types of queries, and it sources its answers with web links. I could see a space for that type of tool, as long as the hairier parts of the chatbot can be filtered away.

Yeah, this effect is pretty strong. After staring at it a bit, the only way I found to 'break' it was by noticing that if I flicked my eyes towards a bird, there was a brief period before the illusion kicked in. By constantly flicking my eyes between each bird, I was able to perceive them as moving linearly.

I mean, it's no replacement for learning something rigorously, but I still find little snippets like this helpful for building intuition. Frankly, I'm not really great at rigor myself, and for areas that aren't my areas of expertise (like signals & systems), intuition is all I really have to go off of. I took undergrad signals & systems years ago and probably could not say anything coherent about the Fourier transform today. Still had enough intuition kicking around somewhere to get the SNR of this ADC signal down via oversampling and an IIR filter, though. I remember churning through blog posts for things like PID loops and Kalman filters as a teen, and eventually got to the point where I kinda understood them. But then when it came time to actually learning them, having that small bit of background helped immensely, since I didn't have to build that basic intuition in the span of a single semester course.

I dug into this last night and got it working with this guide: https://www.derekseaman.com/2019/10/redirect-hard-coded-dns-...

I had issues with just DNAT following some ui forum posts, and I think it's because I'm using switch0 as the interface, with devices across LAN ports on my EdgeRouter. The SNAT masquerade was the key to getting the replies from the pi-hole routed properly.

I was previously using my EdgeRouter as the DHCP DNS server, and using DNS Forwarding on switch0 w/ dnsmasq to forward queries to the pi-hole. With a large cache, this avoided a couple hops for every DNS query on my network. However, this meant that I couldn't see which IP was making the query in the pi-hole query logs, so I've flipped it so that the pi-hole is the DHCP DNS server, and the pi-hole queries the EdgeRouter, which then forwards the requests to public DNS w/ caching. I then assigned every device a '.local' domain in the pi-hole Local DNS tab, which lets pi-hole displays a friendly name for each query in the log.

For completeness sake, here's everything I needed on the EdgeRouter. The EdgeRouter was setup with no VLANs, and with all LAN ports switched w/ a single subnet (switch0 interface exists in the dashboard).

EdgeRouter:

* In the bottom left "System" pop up drawer, set "System domain-name" to "local" (or whatever domain of your choice, like "lan" or "home").

* Services > DHCP Server > [Your DHCP Server] > View Details: Set DNS1 to your pi-hole IP (make sure it's statically mapped!), set Domain to "local"

* Firewall/NAT > NAT: Follow above guide

* Services > DNS: Enable DNS Forwarding for switch0, set appropriate cache size

* Config Tree > service > dns > forwarding: set name server to public DNS server of your choicse

Pi-hole:

* Settings > DNS: Disable all external DNS servers, set custom upstream DNS server to the EdgeRouter

* Local DNS > DNS Records: Look at your EdgeRouter DHCP lease list, give everything you care about a static IP assignment, and then give them ".local" DNS records in pi-hole. SSH-ing in and editing `/etc/pihole/custom.list` may be faster, as pi-hole seems to bring services down and then back up for each entry added via the web UI.

Yeah, it's a real bummer. I posted my list in a sibling comment chain. Looks like others have also posted links to blocklists for smart TVs as well.

This is in the US. If you search online, it seems to be a commonly reported issue, with some articles saying LG started ramping up the ads a year or two ago. Maybe older firmwares don't get the ads?

I've got the LG G1. AFAIK, all the webOS models are affected.

Here are the blacklist domains I've accrued (some rules might be redundant or out of date):

    ngfts.lge.com
    us.ad.lgsmartad.com
    lgad.cjpowercast.com
    us.info.lgsmartad.com
    aic.recommend.lgtvcommon.com
    aic.homeprv.lgtvcommon.com
    aid.rdl.lgtvcommon.com
    aic.lgshopsvc.lgappstv.com
    ^aic.*lg.*
    us.emp.lgsmartplatform.com
    snu.lge.com
    us.lgrecommends.lgappstv.com
    api.thetake.com
    us.lgtvsdp.com
    aic.service.lgtvcommon.com
    lgtvonline.lge.com
    (\.|^)gracenote\.com$
    (\.|^)prehook\.com$
    raw.vidyard.com
    (\.|^)vidyard\.com$
    (\.|^)wistia\.com$

I've heard that the high end Sony Bravia TVs are better in this regard, but haven't confirmed it myself. They are quite a bit more expensive than the other OLED TVs on the market, however.

One thing I've been feeling lately with internet-connected home devices is that I'm being pushed towards products from big tech companies like Google. Google might mine my data still, but at least they'll ostensibly do it competently and securely. Not a great feeling. Despite not really being in the Google ecosystem, maybe my next TV will be one with Android TV support. On the smart home side, I did get into self-hosting Home Assistant recently. I didn't expect much from it at first, but it's remarkable how liberating and useful it feels compared to the one-size-fits-all approach of Google Home or HomeKit. I'm actually excited to try and get some more smart home devices now, beyond just a few lightbulbs.

Good point! I'll have to look into adding that.

What finally got me to setup pi-hole on an old Raspberry Pi was getting an LG OLED TV. The webOS apps for YouTube and Plex are pretty convenient, but the TV was absolutely packed with ads via the home screen and pop-up toasts. To add insult to injury, the home screen would lag for several seconds at boot while it pulled down all those ads. And then I discovered that even after opting out of all the telemetry options, it was making DNS queries for _several_ data mining services that analyze what's being shown on the TV. I didn't Wireshark it to see what API calls it was making, but clearly opting out in the menu wasn't enough. After some passes of scanning the pi-hole logs and adding to the blacklist, my TV is snappier and ad-free. :) Definitely will not be going with LG for my next TV, though. It's mind blowing to me that this is the user experience on a TV that costs over $1k.

As for the pi-hole setup itself, it's working great. It's a great backup to locally installed adblockers, and I have my EdgeRouter as the primary DHCP DNS server, which makes requests to pi-hole. Both the router and pi-hole have caching, and my DNS query latencies are good. Pi-hole also has a nice interface for pointing `.local` domains to local IP addresses, which is much easier than messing with dnsmasq settings on the EdgeRouter.

Ironically, I've been feeling the opposite lately- my day job is embedded, and I was reminiscing about my childhood days when I was learning to code with Scheme and Processing. There's something beautiful about a single laptop being a fully enclosed ecosystem to just play around with pure code, and I basically haven't coded for fun in my free time in a few years. I was even considering trying to learn some webdev to make my own personal site. :P

I still love embedded, and I think it's great for all the reasons mentioned in the thread. As for your question, firmware is quite broad, and there are lots of different routes people take to break into it as a career. At its core, it's a lot of writing systems code, or feature code that runs on constrained systems. Something like CS undergrad systems programming + OS or equivalent should be enough.

After that, I would make sure you have decent breadth: knowing how to read datasheets, bringing up parts, writing a linker script, using peripherals, grokking some standard protocols like I2C/SPI/SDIO, basic circuits knowledge, basic comparch knowledge, etc. The nice part of all this stuff is that you can totally get there with just hobby projects and Adafruit boards. If you find yourself using the batteries included in the Arduino or Adafruit libraries, maybe push yourself to write more of it from scratch. eg. write an SDIO driver to read from an SD card and parse a FAT filesystem.

People with solid software engineering backgrounds are pretty valuable in embedded, so I'd emphasize that as well. Knowing that git exists, unit tests, API design, CI tooling, etc. If you're a Linux kernel hacker, embedded linux is also kind of its own separate world, so that might be a good direction if you have experience there.

The creator, Alexey Pajitnov, was eventually able to see some money from his creation after emigrating to the US and cofounding The Tetris Company. The Gaming Historian channel has a great documentary video on it here: https://www.youtube.com/watch?v=_fQtxKmgJC8

Color neg has been incredibly hard to find all this year, and on top of Kodak's price increases last year, retailers were price gouging in relation to supply. Once I burned through my stockpile, I was basically just shooting B&W stock and digital for a while. It is interesting to see Fuji having supply issues now, though. I wonder if it's related to them cutting Pro400h and C200 previously.