I got much better at this when my kids were born, because it was the only way I could get work done on some of my (computing) side projects. I went from having hours of uninterrupted "in the zone" time during evenings and weekends to having much less time overall, and what time I did have was broken into smaller chunks.
I got much more thoughtful about how I used my time and also got better at pre-planning what I had to do so as to make the best use of it. Mostly the key was to just try to tackle smaller tasks and accept that progress would be slow.
That's been exactly my experience as well. Sometimes doing a little research on a lunch break gives enough direction on how to spend available time later on my project.
Accepting that progress will be slow has been the most difficult adjustment, and applies to more than just side-projects. Choosing books or games also becomes a more strategic decision when what used to be a weekend sprint, turns into a several week marathon.
Pretty much all of these reliability reducers are manufacturers trying to eek a little more MPGs by throwing lots of complicated technology at the problem, which introduces a lot more failure points.
Headlights and taillights on my current vehicle are supposedly around $1500 each, mostly due to a bunch of sophisticated sensors being built in.
Back in the 80s headlights were standardized (in the US at least) - you either had rectangular or circular. They were available at every auto parts store. Now they're a special order item from the dealer.
New synthetic oils are very durable. They actually do last a long time.
There are oil tests that confirm this. Also, 10,000+ mile oil changes are not new, and there are tons of used vehicles on the market, running around with long oil change intervals, and high mileage.
> But the market has spoken! Users prefer Litestream. And honestly, we get it: Litestream is easier to run and to reason about. So we’ve shifted our focus back to it.
That makes sense to me. LiteFS used FUSE, which meant figuring out how to run and mount a custom filesystem. Litestream is a single compiled Go binary that you point at the SQLite database file (and accompanying WAL file).
Doesn't matter. Republican politicans and influencers (if separating the two still makes any sense) framed it as an attack by the "woke" and "radical left" on these fabled american values.
Not maybe so, it is what’s happening. Whether their stance reflects reality or not is not (is it ever with these people?) the point - they’re using it to stir the pot as usual.
Republican politicians and influencers frame everything as an "attack" by the "woke" and "radical left". It makes for a great preemptive distraction when they're actually responsible for most of those things. Bland gray/beige color schemes get decided in board rooms full of uninspiring executive-class types who can't think of anything but trying to cargo cult their way into making the Line go up.
According to Jeff Geerling's video, the main PCB in the 500+ is identical to the 500, same revision and all. Presumably they planned both the 500 and 500+ at the same time so they designed a single PCB that could accommodate both, and then only populated the m.2 parts when building a 500+.
So I don't think they "backed out" rather just didn't have the 500+ ready to launch yet.
Note that the mechanical keyboard is probably one of the major reasons the Pi 500+ took a lot longer to release than the regular 500.
According to an interview on the Pi blog[1], it was "years", with prototypes being built through 2023.
I know the design lifecycle for a product like this is in the 3-5 year range, and adding on a custom mechanical keyboard in a mass-market product like this is a tall order.
Honestly I'm not put off by the $200 price tag. If you use one in person (like at a Micro Center here in the US), you'll feel it's a decent midrange mechanical keyboard. It won't compete on the high end (IMO $200+), but to strap that onto a decent low-end PC in a fanless design isn't cheap, even at the scales Raspberry Pi operates.
They have some margin, for sure, but that's also how they turn profit, which is especially useful since then went public.
At least they're still putting out products like this, that don't really have any industrial/commercial appeal, compared to specialized compute modules for individual customers[2].
Yeah, it's far from ideal, but in my experience its accuracy is better than most anything else readily available, including the official status pages maintained by most tech companies.
Yeah, and not only do you get to see if it's down or not (reddit infamously always says it's up even when there are issues), but you also get to see the raw data of reports. Ofttimes I've seen the trend go up and realized it's a very recent issue - even before downdetector itself recognizes it as such.
Human reading > DD reading >> "All our services are operational" when they're absolutely f--ing not.
It's fine in simpler cases but as we're seeing here, is absolutely useless at providing information on failures in complex systems. It appears that it was one network suffering issues but this was then reported as "EVERY MOBILE NETWORK IN THE UK IS DOWN" because people just go "I tried to make a call and it didn't connect". That could be anything from a single cell tower being hit by a truck to a nationwide power outage.
There are plenty of IoT devices that people want to execute commands on (anything remotely controlled, basically). Polling for commands on a periodic basis introduces lag into that process which is irritating. Furthermore, polling at a frequent interval can end up using a lot of power as well versus waiting in a receive-only mode for an incoming command.
The alternative to polling is unfortunately polling, which is what the article is about.
You can avoid polling for messages, but you have to send packets outbound regularly in order to maintain a NAT mapping & connection, so that the external side can send messages inward.
The latency is overcome this way, so latency is a solvable problem, but this need to constantly wake up a radio every <30s in order to keep a NAT session alive is a significant power draw.
In theory you might be able to avoid this with NAT-PMP / UPnP however their deployments are inconsistent and their server side implementations are extremely buggy.
I'm 24 years into my career now. I think you just get used to this after a while.
I've worked on several big (at the time) software products that our company built and shipped to customers for a while, that we have since abandoned. And in those cases, the entire organization within the company that owned the code was disbanded, so there was no one left to know about it or care about it. I'm not 100% certain but I strongly suspect that there is not a single copy left anywhere in the company of the code for those products - code that I worked on for years.
It's strange thinking that there is basically no trace left of something that I put years of professional work into, but I think it happens more than most people realize. I suppose it's no different than startups that fail and everything disappears.
I also think this is why so many software people end up enjoying hobbies that revolve around physical things, like woodworking or restoring old cars. Having some physical object that you can point to and say "I built that" is kind of nice compared to everything else you've done living on a flash chip somewhere.
I got much more thoughtful about how I used my time and also got better at pre-planning what I had to do so as to make the best use of it. Mostly the key was to just try to tackle smaller tasks and accept that progress would be slow.