bjpirt

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.

The timescales involved in the manufacture of this mirror are amazing. I love the way this guy just casually states things like:

"we then cool the glass ... for a few months"

"the mirror will sit for the next year while we machine the back surface flat"

"that final polishing process ... takes about 18 months"

It's kind of mind blowing for it to take so long to make a single object.

It's a nice idea and really well executed but the second test just demonstrates to me how JS is not an ideal language for a beginner to learn as you're thrown straight into async execution and having to work around the fact that functions execute immediately with arcane workarounds.

I still think Python is the most straightforward to learn, even though the whitespace constantly catches beginners out too.

I recently did the same thing and have packaged it all up as an Ansible setup script [1]. We're using it for a Pi based robot arm [2], so having a built-in access point and a web interface to use for configuring the WiFi means you don't need to rely on the user plugging in any peripherals. Works well!

Incidentally, the framework (headlessPi [3]) we use to run "apps" in the browser and configure the system is all open source and easy to configure for your own use.

[1] https://github.com/headlessPi/headlessPi-setup [2] https://mime.co.uk/products/mearm-pi/ [3] https://github.com/headlessPi/headlessPi

Here's an open hardware robot arm you can build:

http://kickstarter.com/projects/mime/mearm-pi-build-your-own...

I know it's Kickstarter but it will be shipping very soon and you can already download the files to cut your own if you're into that.

(Disclaimer: it's my project!)

Made me laugh but it's a very true statement. When I was driving whilst holidaying in India I realised that the main rule of the road was "largest vehicle wins"! This actually made for quite an easy to understand system with few questions of whose right of way it was.

bike < car < van < truck

which makes sense because if you're the one who's going to come off worse in an impact then you really want to give way - especially if you have a massive painted tipper truck hurtling towards you!

It will be very interesting to see how self driving systems can cope with these local unwritten bylaws.

Or even simpler you can use S3 redirects to send all of your old URLs to their new location on the same host. I'm currently doing this from both an old domain to a new domain and within the same domain and "It Just Works" (tm)

Wow, drilling and filing all of those holes by hand makes me glad I've discovered laser cutters. That's dedication!

Definitely worth a look. One of the guys behind this is pfalcon who maintains the best open development environment for programming the ESP8266 directly[1].

I love the ESP as a platform. It's low cost but still pretty impressive. Having micropython running on it just increases its ease of use, but you've also got Arduino and NodeMCU (Lua) so there's a great budding ecosystem around it.

[1] https://github.com/pfalcon/esp-open-sdk