rohansingh

Sure, here's some ideas:

1. Join the NYC Mesh Slack (slack.nycmesh.net) even if you're not in NYC, just to see how it's run.

2. Read Brian Hall's post, "How to start a community network": https://www.nycmesh.net/blog/how/

3. Read Graham Castleton's "Start Your Own WISP" guide: https://startyourownisp.com/

4. Look around and find folks in your area with a similar interest. If you're in or near a city of any size, I bet there's somebody who's already started or is trying to start something.

If you are a software engineer, working on municipal broadband or starting a local ISP is a really intense way to expand your skills.

For the past year, I've been volunteering at NYC Mesh (nycmesh.net), which is a non-profit that provides fixed wireless broadband in New York. I thought I knew a thing or two about networking — hell, I've even given a talk in the network track at LinuxCon in the past — but working on NYC Mesh really showed me the limits of that knowledge and has helped me learn a ton more.

As someone who unsuccessfully applied for YC W21, and who also launched a product on Kickstarter in the last month, I'm going between "kind of funny" and "I'm so confused".

We didn't make it into YC, though I did get the "you were in the top 10%, please consider reapplying" email. I thought I had some idea of why we didn't make it, and what I'd change if and when we were to reapply. Hell, given that our business has grown a ton, I figured we'd have a strong application.

But seeing this makes me think that I might have some really fundamental misunderstanding of the application process.

Huh. I'd be really curious to see their YC application.

The goal of ethical research wouldn't be to protect the Linux kernel, it would be to protect the rights and wellbeing of the people being studied.

Even if none of the patches made into the kernel (which doesn't seem to be true, according to other accounts), it's still possible to do permanent damage to the community of kernel maintainers.

Thanks! Yup, the hardware has been relatively straightforward compared to the having a reliable, performant backend and good UX for configuring devices. While we've done several hardware revisions, most of the past year has been spent on software.

I've worked across companies in shared Slack channels. And also linked Facebook Workplace instances.

Doesn't the instrument itself change over those long time periods?

Yeah, looks like ACME is indeed free and includes wildcards: https://zerossl.com/letsencrypt-alternative/

No, it's not. AFAIK, NYC Train Sign went out of business over a year ago.

I hope to have an announcement on that in a week or two. Building and pricing hardware is hard!

Just to clarify though, you don't need a Tidbyt device to use the Pixlet runtime. It outputs GIF's and WebP's that you can "run" or serve wherever/however you'd like.

Guessing I have the same beard trimmer as you, with a micro-USB port. It's great for travel but sucks to have to carry around an extra cable now.

I'm thinking of trying to convert it to USB-C, similar to what this guy did: https://youtu.be/V-vFtiDYiIw?t=538

Sure thing. By the way, I should have said esp32.net, not esp32.com. The latter is the official discussion board, but the former is an unofficial reference site that's incredibly useful.

If you're confident in your design, you can send it off for assembly at a manufacturer that does PCBA. They'll handle the SMD soldering for you.

A good place to start would be reference schematics from Espressif for their dev boards, and schematics from open ESP32-based boards from other vendors. Check out esp32.com for a list of boards.

With those schematics and KiCAD, you should be pretty much set. Take an hour or so watching KiCAD tutorials, it'll be worth it.

Also, spring for an ESP32-WROVER-KIT and use it to prototype with a dev board. That kit also supports JTAG debugging, which can be quite handy.

Just a heads up, there's been a fair number of bugs and issues around sleep mode. Most of the problem seems to be in software and the situation has improved, but you might want to look into the exact state of things.

I'm working on an ESP32-based product that doesn't use sleep mode, but I've noticed people reporting issues about sleep mode on GitHub and in forums.

Nothing to see here:

  Thought it was a bug but it's just a feature difference between browsers.
  
  The first time the page loads with an anchor in the url: `http://somesite.com/#gohere` it should load and go to that location on the page.
  
  But if you scroll to the bottom for example, then reload the page or put the cursor in the URL bar and press "Return/Enter"... the page will simply reload exactly where you are.

> CC companies in the US made the moronic determination that the American consumer could not handle the complexity of the PIN

Or maybe they did the math, found that the average US consumer has a handful of credit cards, and figured that if they put a PIN on their card it would get used less. Resulting in less profit for the credit card company.

What makes you think that whoever would be responsible for approving the change would somehow know better and catch the issue?

I don't think "how to draw a bicycle" is the thing that your brain tricks into thinking that you know. Instead, it's "what does a bicycle look like?"

If you ask most people if they know what a bicycle looks like, I think they'd tell you, yes, definitely. But really they don't. They know that it has a couple wheels and some sort of metal tubes, and that's a workable mental model to convince yourself that you know what a bicycle looks like.

People weight "career downsides" differently. A lot of folks who are further in their careers are done trying to climb the ladder and would be happy working remotely.

It's probably more about control than cost. Our company's product is similar to Automatic's, in that, in theory, you could have everything be done on-device and not need a proprietary backend at all.

Other than the fact that this is difficult to keep up-to-date and working, it increases the hardware cost significantly. Instead of having a very cheap microcontroller handling everything, you might need something more capable and more expensive.

Development cost goes up too, since instead of writing your integrations in Python, Go, JS, or whatever, you need to write your integrations on your embedded system.

It's not a binary choice, and honestly it doesn't take a whole lot on our part to make the product open.

Also consider:

1. The choices we make on mitigating the possibility of the product being waste can actually improve our product. For example, because the product can be reprogrammed easily, we can enter verticals that wouldn't be possible otherwise. Or because our hardware is well-architected and documented, it's easier for us to iterate on it.

2. If we fail because we couldn't figure out a way to make the product responsibly, that's a good thing. I'd rather we fail early than put out waste.

> That said, I think your plan really only seems to help tinkerers. There may be no way around that for what you're building, but I think graceful degradation in functionality is preferable, such as having a maximal-functional no-cloud mode. The few smart products I buy have a mode like that.

Great feedback. A limited "no-cloud" mode is something we could possibly do, I'll think about it.

I think you are correct that it would really only be a small number of people who would be able to use our docs and write their own firmware for our device. But we want to make it relatively easy to switch between public firmware variants.

So even if you're not an engineer, you can choose to try a different flavor for your device. And if we have to completely shut down our services, you could do that as well.

I'm working on a IoT device and this is something that my cofounders and I have discussed a fair bit. While we want to succeed, we know that most businesses fail, and we don't want to put out products that become waste.

We're working on mitigating this by having an open hardware platform. The idea being that, even if our cloud service isn't up, you can re-flash the hardware to do anything you want. And you can use our documentation to do it so you don't have to reverse-engineer everything from scratch.

I'd like to see more companies follow this approach. I've at least a handful of IoT devices that are effectively bricked, which sucks because I know they have decent and usable innards.

Dashboard must have updated, because it now says that Argo Tunnels is offline.

I've been impressed by the Go Time podcast from Changelog. Good topics, interesting interviews, well-researched and well executed. Not a huge fan of the other podcasts on that network, but Go Time seems good.

Does Amazon's instruction to him to stay home override his rights as an employee to organize and participate in collective action?

I don't actually know the answer. But in general, I'm guessing that you can't end a strike by ordering all employees to stay home and then firing them if they don't.

Ah, got it. It's still incorrect though. With the incident a couple days ago, I couldn't `git push` for a couple hours.

I don't get it. Their own incidents tab on the same site shows four incidents this month: https://www.githubstatus.com/history

I'm not sure how that results in 99.98% uptime on the other tab.