rcoder

The physical connector is unfortunately not an indicator that the hardware and software needed to drive an e-Ink display will be similar to an LCD. Sadly, e-Ink displays require custom drivers to function at all, and in particular partial refresh (needed to get sub-second updates) requires targeting known dirty regions of the display and updating just those…hence the extra ghosting in the higher-speed mode of most ebook readers & etc. that use EPDs.

FriendlyElec has a range of boards under their NanoPi brand that might fit:

https://www.friendlyelec.com/index.php?route=product/categor...

The NEO Air in particular is a very compact board using an Allwinner chip, which works pretty well under Linux including such niceties as support for the integrated power management chip.

I also recently got a couple of the Space Cats Jeter Nano boards. They’re more on par with the VoCore, performance-wise, but with a lot of GPIOs on more hobbyist-friendly (read: breadboard-ready) connectors.

I strongly disagree. Firing someone while they’re on leave sends a direct signal to anyone else considering taking leave: “watch out, you won’t be able to defend yourself if you aren’t here.”

ICs follow the lead that executives set. A chilling effect like this will cause folks who most _need_ the leave — single parents, people with family in need of care, or those struggling with their own health issues — to second-guess their choice, while those who can just walk away w/o any real risk can go ahead and try taking time away.

It also puts the lie to the idea that employer-subsidized leave beyond the federally-protected time window is an entitlement rather than an easily-canceled perk. We all know that rationally, but a BigCo obviously exploiting that trust is a good reminder that the company (any company) is not there to help you, they are not your family, and you have to be ready for this kind of “switcharoo” whenever the numbers (or politics) justify it.

Yep, you're right. My apologies. It has been about 25 years since I actively studied or spoke Japanese, and I was typing on my phone.

My explanation was trying for "understandable" but may have veered into "problematically over-simplified," not to mention insufficiently copy-edited.

I’m not sure this is universally true, but in most contexts I’ve heard while studying Japanese and visiting Japan, サラリマン (sarariman) indicates someone with the kind of lifetime-employment, “I live in town in a coffin hotel during the week and only see my family on the weekends” job that used to be common for white-collar workers.

The identity, uniform, and work ethic are all part of the package. It’s been a while since most big companies in the US could claim that kind of life-long career and mutual loyalty was likely or even desirable, but early IBM might be an apt comparison., down to the dress code, company songbook, and 40-year tenures for senior staff.

I literally can’t tell if this is a joke. I’m going to treat it as earnest, because even if you’re trolling this is HN and every mention of cryptocurrency will get _someone_ nodding along in support.

Censorship resistance is only meaningful if there are actual people exchanging ideas and building community. Cryptocoin and 100% free speech is a perfect recipe to create an online space even more dominated by trolls, bots, and conspiracy theorists than Twitter is today.

Unfortunately, between Musk’s obvious enjoyment of manipulating markets however he can and Dorsey’s increasing focus on dWeb/Web3/“magic crypto sprinkles” I imagine they will run full speed towards more or less exactly the model you describe.

“Every tweet is an NFT now! Popular accounts charge Twitcoin to follow them! Advertisers can pay people Twitcoin to follow and retweet!” Etc. Etc.

I’m a huge eink display fan, to the point of owning multiple tablet-shaped devices with larger EPDs. I agree that the reading experience for effectively static text and b/w images is great, but once you introduce any scrolling or transitions it quickly becomes worse than a standard LCD. UIs really need to be optimized for eink, just like they should be designed differently for smartphones, big desktop displays, and screen readers or other assistive tech.

W.r.t. power: I don’t think EPD magically runs on less power _while refreshing_. So again, if you are mostly displaying static text and figures —- like in an ebook reader —- it’s great. If you’re constantly repainting the UI, less so.

As much as we may like to think programming is all about staring at walls of text in editor buffers we’ve carefully tuned for readability, IME at least I spend a lot of time switching between an editor, live view of my running app, documentation, log and trace views, etc.

Neither a slow refresh (4-10 fps) with major ghosting or a glacially slow (<1 fps) one that’s clean is actually a very good trade off with most modern workflows. Including ones that are nominally about text, like coding.

“…a recovering alcoholic talking about the dangers of just one drink.”

So, one of the things you learn pretty early in recovery is that there is no “normal” when it comes to addiction.

However, there are _patterns_ of denial and implicit social construction around risky behaviors that most people only believe matter for “alcoholics” and other obvious “losers”.

Something can be both toxic (booze, cigarettes, online fake conspiracy echo chambers) and relatively benign in small amounts. That doesn’t mean that foregoing them is bad in absolute terms.

OTOH recognizing that toxicity instead of ignoring it can help to avoid the “only happens to other, weaker people” trap. Said trap lets many people slide much further into self-destructive behavior than they could otherwise with a bit more self-awareness and compassion.

Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it.

Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy.

Furthermore, these modules could themselves expose language-specific APIs; ergo `mod_perl` and its ilk, which provide a bunch of useful building blocks for a full-stack webapp but are entirely specific to Apache's module API (vs. something more standard like FCGI, WSGI, etc.)

I've worked at some shops with heavy investments in Apache-based application servers and the cost of moving away from HTTPD modules and towards a more standalone, Apache-free implementation was generally quite high. Usually you need some other forcing function (rewrite in a new language, microservice decomposition, etc.) to justify the investment.

You can build a Merkle tree from any data that is append-only; Git does this, as do ZFS and Dat/Hypercore. That lets you make strong assertions about data integrity, even without blocking local writes.

Now add a mirror: git upstream, FS snapshot, immudb replica, etc…or even just an outside log of the merkle proofs themselves. Then, if your database ever fails a check against that proof, you know the data has been modified, not just appended to.

To use a familiar Git workflow example: you can do whatever local writes you want, but if you disallow force pushes no one can erase history on the upstream repo.

Put another way: if you have immutable backups you don’t need a blockchain to ensure data integrity. OTOH, if you can’t trust your own infrastructure even as far as a secure remote backup you have other problems that a blockchain won’t solve either.

I've been about 90% standing/10% sitting for the last several years, and while standing is great for me, the ergonomics of switch to and from my Aeron -- bought 15-ish years ago from a startup closing up shop -- felt less so.

I passed along the Aeron to my wife, who prefers a supportive chair and has also obviously been working from home, and got a Fully Tic Toc stool. It forces me to maintain something like healthy posture and keeps me at least gently moving throughout the day, and as a bonus fits neatly under the desk when I'm working rather than forcing me to find space elsewhere in my very compact home office.

I've found that for my 40-year-old knees and hips some sort of motion was necessary to keep from getting sore by the end of the day. The Tic Toc helps with that, as does the balance board I pull out when standing for any length of time. (The board is a Fluidstance, which is stupidly expensive for what amounts to a skateboard deck on top of a piece of bent sheet metal, but it feels a lot better than standing still and has held up really well so ¯\_(ツ)_/¯.)

Obviously this kind of setup isn't good for everyone, but I really like it.

Just in case the word "conduction" triggered the question about health risk: in this case it just means the sound is transferred by direct contact of the resonator on the speaker with your cheekbone (well, as direct as going through the skin can be). There's no electrical signal going into your body, just vibration moving through your skull directly to the inner ear, rather than via air into the air canal.

Music is actually pretty unsatisfying at any volume above background levels in an otherwise-quiet room, since any significant bass through the conduction 'phones actually makes them jump out of contact with your head, resulting in a buzz you can feel + hear. Calls, podcasts, YT videos, etc. all work great.

RK3399s make great bang-for-the-buck boards, but the idle power consumption is pretty high. I’ve been kicking around one of the Khadas VIM3s which has a newer Amlogic SoC on it and like what I’ve seen so far. It’s a significantly more expensive board, though

There are plenty of things that an RK3399 (or the new Rockchip being used in the OP) can handle just fine.

I was definitely interested to see that this new chip supports up to 8GB of RAM. I think there are a lot of interesting applications for RAM-rich, Gig-E bearing nodes that can run off a battery. (Examples: Redis at the edge, “Field” PostgreSQL replicated to the cloud when possible, nested VMs protecting trusted “firmware” from remotely-loaded containers and machine images, etc.)

One thing I haven't seen mentioned here yet: Thonny explicitly supports Micropython for embedded systems development: https://github.com/thonny/thonny/wiki/MicroPython

IME Thonny is a great sketchpad for Micropython ideas, and makes work on that platform nearly as easy as locally-run Python code.

If you're online interested in limited quantities, this Sharp display might well fit the bill:

https://www.adafruit.com/product/4694

It's a "memory LCD", which has very low no power drain when idle, but has an LCD's refresh speed (i.e., fast enough to display video).

You can also get some decently-documented eInk boards from Waveshare in 1" to 13" sizes, though the costs are definitely too high for anything but one-off Maker projects:

https://www.waveshare.com/product/displays/e-paper.htm

You may also find the PaperTTY project interesting for your TUI:

https://github.com/joukos/PaperTTY

There's nothing stopping you from doing your development, testing, and deployment against the base OS on your Pis.

Even beyond pure learning opportunities, though, there are good reasons to containerize applications even on a system as low-powered as a Raspberry Pi.

For example: if you have a k8s, Docker Swarm, Nomad (disclaimer: I work on the Nomad team @ HashiCorp), etc. orchestrator in place you can keep workloads up and running even as you take down individual machines. (This can help a lot for OS upgrades, replacing failing hardware, disk upgrades, etc. on a running cluster.)

Likewise, you can develop + test your containers on a more performant or convenient machine (like a PineBook Pro, or VMC on a Chromebook) and deploy to the Pi(s) without having to manually map your FS layout, dependencies, etc. to Raspbian or another Pi-specific distro.

It's not something you _need_ to do, necessarily, but neither does that mean there isn't value, esp. for folks already comfortable with a container-based deployment workflow.

If you're running one of the recent Debian-based distros for these boards software compatibility isn't a big issue. Each SoC has its own funky firmware + GPU blobs needed for bootstrapping, they almost all use the same ARM64 ABI and can run a huge number of OSS binary and source packages.

How would you power and cool such a beast? What kind of workloads would benefit from that much RAM while running happily on a CPU that fits on a typical SBC layout?

If you want a tiny workstation-class system, there are entirely decent mini ITX board you can stuff a recent AMD or Intel chip and tons of RAM into. You'll need a desktop-class cooling system and power supply, though, and it'll still have the footprint of 6-8 of these board, and probably about 15x the total volume and power consumption.

The ARM SoC (system on chip) CPUs these boards use often cap out at supporting 4GB of RAM. It's also much more expensive and power hungry to stuff a bunch more DDR4 onto a tiny board, and often messes with the layout (i.e., of you need two RAM chips instead of one).

The rk3399 CPU on this board also dates from 2016[^1] so adjust your expectations accordingly. :)

[^1] It's also a well-documented chip that's cheap, provides a nice performance bump over an RPi, and requires fewer proprietary blobs.

Do you live in Portland? How about your family: kids, parents, siblings? Do you own businesses here? Have you spoken to anyone involved in the protests, or local business leaders?

All of the above are true for me, and I was born here, and I for one applaud the new restrictions on facial recognition.

If your answer to most or all of the above questions is "no", please reconsider telling those of us with actual lives here here how we should want to be policed and why.

I've done a fair bit of tinkering with ePaper displays attached to little Linux and MCU boards, and it is not trivial. Few if any have touch overlays, the graphics APIs are usually at the level of: magic initialization happens in this opaque chunk of bit-bashing, then you get a raw framebuffer; have fun!

You absolutely could homebrew a touchscreen ePaper "slate" with a similar broad set of features, but much like the Libre laptops (Purism, Novena, etc.) it's going to be slow, power-hungry, and chunky compared to a complete consumer device like the reMarkable.

...and if all car manufacturers bought engines from the same factory (TSMC), used the same satnav (except one brand, who had a slightly-worse in-house clone), and an accelerator and gearbox from exactly one source (Google search) would you be more concerned about anticompetitive behavior? What if the manufacturers were allowed to produce "accessories" like batteries, tires, and child seats that refused to work in any other car, and actively sued repair shops that weren't official dealerships?

Apple and Google may be competitors, strictly speaking, but the reality is they've pretty well carved up the market between premium buyers mostly concerned with fit+finish, prestige, and compatibility with other Apple devices, and the operating system and network infrastructure for, well, everything else.

It's absolutely a duopoly, and so minimally competitive: either Google or Apple would happily claim leadership status, but neither party really wants the other to go away lest actual competition or government intervention cause them to lose control of their patch of ground.

FWIW I'm regularly able to get ~12 hours on a charge on my PBP with normal terminal and qutebrowser or epiphany sessions running. That's closer to 3W under load, not 5W at idle.

Also, while power usage does go up a bit when the CPU is more fully loaded, it definitely doesn't jump up to 30+ watts like my ThinkPad does.

The Rockchip SoC in the PBP isn't impressive compared to the ARM chips going in current-gen high-end smartphones, but the max TDP isn't anywhere near what an Intel or AMD laptop chip cranks up to.

That also means a truly fanless computer with a monolithic, user-replaceable battery.

There's are certainly workloads where a faster, symmetric multicore x86 chip will win on computer per watt, but it's not as cut-and-dry a win in real-world usage on a laptop as it might be on (say) a heavily-loaded server.

My personal stance towards high-risk startups changed dramatically a few years ago when I took on a big chunk of responsibility for my parents' retirement. My "nest egg" that could be absorbed in a pre-revenue startup has more or less been transformed into the house they've retired into. Having my first kid a couple of years later only compounded the effect. (They're also mutually-dependent, since my parents provide essential childcare while schools and daycare are shut down due to COVID. My parents not having to work right now is literally a matter of life and death given their age and medical histories.)

Regardless, "smart, sustainable work that will support my family" doesn't really map to the intentionally-accelerated make-or-break pace of most incubators and funds. Nor do those programs naturally align with founders who want to create a solid long-term business working from sound operating fundamentals (positive cashflow, measured and even conservative hiring, working to the team's strengths) instead of chasing the next exploding market and "faking it until you make it".

Coincidentally those safer, longer-term plays are also the ones most likely to actually build generational wealth and financial independence for people starting without either. The lack of a safety net (or the presence of one that you're thoroughly entangled in for others' sake) makes all-or-nothing, giant bets far less tenable when you aren't effectively free from having to worry about mundane details like housing or medical costs. That in turn discourages if not de facto shuts out both the least privileged and those with meaningful resources but too much to lose if it all goes wrong.

There's plenty of prior art beyond Rosetta to look at. MS has already done this for Windows on ARM, and simultaneously across ABIs via WSL. Linux offers QEMU-based "on the fly" emulation of different instruction sets based on execution-time examination of the ELF binaries. x86 BSDs have long offered Linux emulation. Even ChromeOS offers lightweight containers for Android and Linux apps.

Apple is actually pretty far behind the curve here, at least in terms of end-user-accessible features. Presumably that means they wouldn't have to innovate too much to get x86/ARM translation working, even for binaries that couldn't be readily recompiled to support the new chips directly.

If you imagine "IoT" as "a bunch of Linux boxes pushing around multi-MB JSON payloads over fast network pipes" then yeah, this would be a bad deal.

For datagram-based protocols like CoAP which are explicitly designed to let you control bandwidth usage down to the packet level this should be fine. 1kB of data (which is honestly large for a normal telemetry or sensor payload) is really cheap, even at $0.10 per MB.

Many of the devices and network architectures in this space are made to literally wake up a few times a day and push/pull data, not keep idle connections up and running. Your "runaway loop" would kill the device's battery and cause a bunch of other red flags in such a topology long before it racked up substantial bandwidth charges.

Semi-related to this and the recent Haiku R1/beta2 announcement: just for giggles, I installed that inage on a USB3 external SSD and fired it up under KVM, and was suddenly greeted with a faster, more polished desktop environment than Windows 10 or Ubuntu offer out of the box. Consistent UI patterns, applications that open in less than the 250ms perception threshold, and some truly useful utilities installed (a fast POSIX terminal, programmer's editor, media viewers, basic but serviceable WebKit-based browser, etc.). All of it happy to run in 1-2 GB of RAM and two cores of my six-core laptop, even under virtualization.

Running on an Atom-based SBC I had on the workbench, it's even more responsive.

Yes, building native apps requires at least a basic knowledge of C++. No, it won't seamlessly run the latest React SPAs as well as Chrome. The driver situation isn't as good as (say) Linux or FreeBSD.

And yet, the focus on providing a productive environment for normal computing tasks instead of endless up-selling to an app store, countless background updaters, and vendor-bundled crapware is like a breath of fresh air.

This is what we've lost in the move to impose ever more layers of services, unique per-app GUIs, and ubiquitous (even gratuitous) packaging of "webapps" in lieu of targeted, native apps.

To be clear: this isn't a unique property of Haiku. A nice clean install of FreeBSD or Debian has many of the same properties, and I have reason to believe that a Windows 10 "distro" based on something like Server Core could be similarly light and responsive.

Unfortunately, the major platform providers seem deeply uninterested in building systems that don't push you aggressively towards newer hardware, loads of subscription services, and "strategic" software bundles no one asked for.

So just to make sure I'm clear: the author of this post is (according to the "about" page on the linked site) is "an angel investor, founder, podcaster, author, and general startup-helper" who is wildly speculating about the causes of and solutions for one of the most complex and nuanced areas of medicine out there.

Then he indulges in exactly the kind of casual, "if you just do this you'll be _fine_" sort of reasoning from armchair diagnosticians that leads people _actually_ suffering from mental illness to think, "oh man, I guess I'm just undisciplined and all of this is _my fault_."

I'm sorry, but no. Just stop. Your "helpful tips" equate the _symptoms_ of mental health issues (lack of sleep, inability to focus and plan, over-consumption of alcohol, etc.) with the fixes that are available to you if you "just try harder'.

Telling someone deep in debt that smarter decisions made long ago would have avoided their current problems may be _accurate_ but is neither helpful nor compassionate. Likewise, telling anyone who'll listen that acute mental health crises can be prevented proactively by "simply following these few tips" does less than nothing for those suffering right now: in fact, it worsens the perception that their illness is their own fault, it's too late to make any improvement or progress, doctors will just try to sell them snake oil so why bother, etc., etc.

Perhaps if the author had said something like, "I too have struggled with mental health and found the following things made a difference for me. YMMV, and of course you should only attempt self-fixes in combination with treatment by a qualified professional, etc. etc." He did none of that, nor is he a trained psychiatrist or counselor, which makes his "hard-earned wisdom" suspect to me.

"Be more like me and you too can be successful/happy/rich/etc." is not a terribly useful kind of advice. Likewise "the trained experts in the field don't want you to know this, but the solution to $really-hairy-problem is just to $follow-my-convenient-five-point-plan."

In case my umbrage at the tone and content of this article wasn't clue enough: I have been diagnosed as bipolar, with concurrent major depression, anxiety, and substance use disorder. Many of the symptoms and aggravating factors were buried or even encourage by the "startup life" and I'm deeply skeptical about VCs and founders who purport to care about the mental health of their peers and employees while making a constant push to "hustle", "put in the hours", "not settle for a lifestyle business", etc.

Throughout my career my manic periods have consistently been the most productive weeks and months of my working life, but the corresponding depressive episodes usually resulted in me being fired or walking away from an otherwise-decent job because no one understood or bothered to ask why a "high performer" had suddenly become flaky and uncommunicative. Advice on how to "prevent" mental illness from those who have neither suffered from it or been trained to treat it is _not_ going to make things better for me or folks with similar experiences.

This IMHO defends, not defuses the preceding argument. When there was risk of the market crashing, the federal government injected trillions _into the market_. This primarily benefits those with significant capital investments, not those whose ability to provide for themselves and their families is tied directly to regular employment.

Small business, retail and service workers, and employees whose jobs can't be trivially moved online are in desperate straights right now. The Fed's action did almost nothing for them.

> It's not perfect, particularly for lower income people...

I don't think many minimum-wage retail or service workers can just "vote with their feet" and easily get another job, especially if you don't consider major changes in location and hours to be a non-starter.

For folks with kids, or who depend on public transit to get to work, "up and moving" isn't really an option. If you're one missed paycheck away from eviction, bankruptcy, or arrest due to missed fines or court fees then you can't play "hardball" with your employer.

Saying the arc of history improves overall cruelly glosses over the reality today for millions of Americans.