bjpirt's comments

Yeah - big fan of the FM / FM2n (I've also got the latter)

The FM3a always really appealed, but the more I think about it the less it appeals. Although it's a mechanical shutter, the electronics are still pretty complex and if they die, there's so few of them that there's very little way of repairing it with salvaged parts. I've also heard that because they are not as reliable as the previous FM / FM2 iterations

I've been pondering the same thought recently but applied to analog cameras. Analog cameras have evolved over time, approximately according to the following:

- fully mechanical

- mechanical shutter with light meter

- electronic control of shutter, mechanical advance

- fully electronic shutter and advance

Broadly, what I'm finding after digging in to restoring some cameras is that most of the cameras from the first stage can still be fixed and made to perform close to when they were new. The second still work, but the light meter can die (simpler light meters may be repairable, later ones not so much). The third and fourth stages - once they die, there's no repairing them. And when you look at digital cameras, there'll be very, very few of these that last long into the future.

This bears out the 'Lindy Effect' mentioned in the article.

One of the nicest data through sound implementations I came across was in a kid's toy (often the best source of innovation)

It was a "Bob the Builder" play set and when you wheeled around a digger, etc the main base would play a matching sound. I immediately started investigating and was impressed to see no batteries in the movable vehicles. I realised that each vehicle made a clicking sound as you moved it and the ID was encoded into this which the base station picked up. Pretty impressive to do this regardless of how fast the vehicle was moved by the child.

Not cheap, but you can get a Leica that doesn't even have a screen, it's all manual and just treats the sensor as though it were film stock. One of the things I like about the Leica digitals is that they are still rangefinder cameras so your experience of using them is still through the viewfinder and much more akin to an analog experience because of the manual focus / exposure / speed control. Now I just need to save up :-)

As others have said, the Nikon Zf is a nice manual feeling digital option too.

This is one of my favourite distractions when watching Sci-Fi films set in the future - spotting objects from now. For example:

- In Luke's home in Star Wars IV there's a lot of Tupperware - https://projectswordtoys.blogspot.com/2014/02/in-praise-of-t...

- In Alien, Ripley drinks from a Tupperware mug - https://twitter.com/EverRotating/status/1156650673972363264

I like the principle of this and have kind of done it myself previously, however I'm currently finding it's a _lot_ harder to consider blowing up your life when you have kids that are old enough to care. I think the resentment having your life blown up for you makes this considerably less appealing...

For those who favour Docker - you can do this:

docker run --name archiveteam --label=com.centurylinklabs.watchtower.enable=true --restart=unless-stopped atdr.meo.ws/archiveteam/reddit-grab --concurrent 1 [username]

I've had the displeasure of re-implementing some awful systems written in a no-code platform.

If you're using low-code, you're still writing software, and good software is more than a bunch of if statements and function calls, it's a well-considered and understandable architecture too (or it should be)

Low-code makes it easy for non-programmers to write systems, but there's no reason you would expect these non-programmers to understand how to architect these sytems well. This (IMO) is why systems written in low-code tools often become unmaintainable piles of mush.

We've been using trivy [1] to audit the container builds we've been producing for a relatively security focussed project. As well as scanning for OS package level vulnerabilities it also scans for reported vulnerabilities in NPM packages. Works well for us.

But the other complementary approach is to lock down other things - so for example, if you're running in a container, make sure that container can only talk to the proxy in front of it. That way, even if there was some kind of malicious code running in one of the modules, there's no way for any data to get in or out (unless it finds a way of injecting into any web input/output, but then you need to be scanning for that too)

[1] https://github.com/aquasecurity/trivy

Having big flashbacks to the switch from PPC to x86 here. Rosetta worked relatively smoothly during that transition so fingers crossed it will be ok here too.

Though with Docker support on the mac already being a second class citizen to running on Linux I wonder if a lot of devs will stop using macs for dev

I'm a happy Postgres user and recently did some work with a government agency using Oracle - the thing that shocked me most about Oracle was the lack of transactional DDL operations which was something I'd just taken for granted in the Postgres world.

Wow, that's a particularly nasty clickbaity headline. He only dropped out because of the disease that caused him to be bedridden for those 11 years.

Maybe "Student was bedridden for 11 years..." would be more accurate.

I wonder if that's because heads would always win

From personal experience: using WebSockets for realtime communication with a microcontroller works really well. I've put together a number of products using ESP8266 to do this and serving out the HTML/JS from an embedded web server. Works particularly well for streaming out the state of sensors on the device.

The main issue I had was that only HTTP was well supported on the Arduino/ESP8266 platform and as we all know that's fallen out of favour. Unfortunately, it also limits what you can do on resource constrained microcontrollers. Having HTTPS in this library opens up the ability to build an SPA which was something I'd always wanted to do.

I don't see any mention of ESP8266 on their site but hopefully, as probably the most widely available IP enabled microcontroller, it will be supported too. Time to do some more digging into getting it running.

edit: I obviously didn't look closely enough - there's recently been added support for ESP8266 - happy days!

I love threads like this as I always end up discovering a new gem. I'm just going to post some of the things I've read recently in case you haven't - it doesn't really matter if a book is recent if you haven't read it I guess.

This definitely doesn't fit the category of recent, but I've been really enjoying working my way through some Asimov classics. If you haven't read Asimov I'd highly recommend him.

Give the Elijah Baley series a try first: - Caves of Steel - Naked Sun - Robots of Dawn

and then move right on to the Foundation series.

I'd second the other recommendation for Three Body Problem, though the third book went a little crazy at the end for me :-)

I've also been really enjoying reading some Verner Vinge novels: - A fire upon the deep - A deepness in the sky - The Children of the Sky

I was pleasantly surprised to see this too - I bought a charge controller directly from Hugh to load control an immersion element direct from DC solar and he was extremely knowledgeable and helpful.

Alternative takeaway: Javascript is so widely deployed that most languages have found a way to compile to it

Personal WASM anecdote: I just implemented a WASM based 3d model boolean operation for three.js where I can intersect two models together. The pure js version ran in around 10s on a relatively simple model whereas the WASM version did the same thing in a little under 1s. I've been very impressed by the technology so far! Obviously this kind of CPU intensive work is where it can shine and it's a useful tool to have in your toolkit.

Not sure why this comment is being downvoted - seems like a perfectly valid concern, particularly if you've read Rainbows End by Verner Vinge

Good work, however a little feedback...

This works fine at lower rates but once you hit anything greater than 120 or so there's a noticeable lag between hitting the key to rotate and the shape actually rotating - enough that the shape will often have moved a couple of spaces by the time it rotates which makes it very difficult to play.

Not sure if that's inherent to the framework or just how this particular version is programmed.