dperfect

> Output: Digital services, site subscriptions, digital assets, in-game items, NFT's representing real world assets held by trusted companies (wine, event tickets, tokenized securities).

> None of this requires oracles and exists today.

While I only mentioned oracles specifically, I should have clarified: I'm referring both to oracles (making queries to external data sources and providing the results to the blockchain), and to external code that interprets data stored on the blockchain and acts on it. I'm not sure if there's a name for it in common use (I'd call it something like a "performer"). Either way, the issue is the same as that with oracles; whatever decentralization or smart contract guarantees you had on the blockchain disappear as soon as you have external code interpreting blockchain data to then make decisions in external systems (digital services, site subscriptions, digital assets, in-game items, NFT's, etc). If oracles provide inputs to the blockchain, these non-blockchain pieces of code provide the real-world outputs.

Example: even if somewhere in the blockchain I can prove that I should own something in the real world, it's still up to your site/service/app/whatever to honor that through external code. If it doesn't honor it, I'm stuck relying on traditional legal means to intervene, just as with any other standard contract. That legal system – as flawed as it is – tends to work for contracts written on the back of a napkin, stored in a SQL database, or coded in a smart contract (though that's probably the most questionable at the moment).

If I'm wrong, please correct me, but I've been interested in this stuff for a while, and I haven't found anything that actually solves the fundamental problem of oracles and the interpretation of blockchain data. That problem is important because it undermines many of the primary selling points of smart contracts.

> Your mistake is thinking that just because the base layer is decentralised that we're somehow not allowed to connect to companies we choose to trust

So, honest question: why care about the base layer being decentralized if in the end, you choose to trust those companies? What did the decentralization do for you in that interaction?

I completely agree with the author. I've been reading a lot about the EVM, and while there's some interesting technology involved, it feels unlikely to be able to support any worthwhile applications outside of blockchain finance or moving $ around the world[0] (since the code can really only directly reference the blockchain itself).

It's a bit like playing with a programming language in a sandbox that has (1) has no I/O functions[1], and (2) has enormous costs associated with even the most basic of computations. Ok, it's not like that; it is exactly that.

Sure, you could build a crypto toy and convince some suckers to transfer some of their wealth to you, but calling it an app platform or the next evolution of the web is definitely a stretch. I sincerely wish that wasn't the case (I'd love to find an exception), but that's what I've come to conclude.

[0] Don't get me wrong, there's tremendous value in being able to move money around the world without the blessing of governments and central banks!

[1] Any interaction with entities outside the blockchain require oracles, and at that point, you might as well throw away the other benefits of being on a blockchain.

> We've reduced our overall sign-in speed by about 20%

So it's slower now, or did you mean to say you've reduced the time to sign-in?

I apologize - I truly don't mean to bash GIMP and I appreciate all the work the volunteers have done. It has come a long way and appears to be getting better with every release.

My reliance on adjustment layers and non-destructive workflows probably doesn't represents the majority of GIMP's user base, and that's ok. I can't really use it seriously for photographic retouching until it does have that, but I'm glad other people get a lot of use out of it, and the other features that have taken higher priority surely make sense for a great number of those people that do use it regularly. I hope that drives more usage, donations, and development.

The fact that Photopea is better than GIMP in so many ways (does GIMP still not have adjustment layers for non-destructive editing?), and was created by one person is a little depressing, but also inspiring at the same time.

I agree – the number is probably insignificant, but I don't think you have to restrict your estimate to people who hate AMP. Basically an average iOS user (likely using Google as it's still the default last I checked) who in the past installed an extension to block unwanted content (ads/malware/etc) may be blocking AMP links without even knowing what they are.

Not sure if this is DIY enough for you, but I'm using an MQ131 (about $20-$30 on Amazon, probably cheaper directly from China [1]) in an air quality monitor I'm building. There's an Arduino library for it [2], and from what I can tell so far, it does work, though it's probably not super accurate. It's also somewhat sensitive to environmental factors, but you can correct for some of that with known temperature/humidity.

[1] There are a few different kinds of MQ131 (for high and low concentrations); you'll probably want the low concentration one. I also removed the bare sensor from a breakout board I purchased so I could access it directly from my custom PCB.

[2] https://github.com/ostaquet/Arduino-MQ131-driver

> They got a bonus of $20 for every question they found where their answer was more correct than the original.

> We need to put care into our systems. We need to build checklists and peer review and resilience into the way we express our carefulness.

Yes – the systems help, but proper incentives are also super important. Granted, designing a system wherein the incentives are properly aligned with the goal (and not easily manipulated; shortcuts can and will be exploited by humans and ML algorithms alike) is no easy task.

I'm all for cleaner air (especially reducing dangerous gases and pollutants), but at what point does the over-sterilization of our environment (specifically with regard to microbes) do more harm than good? People in my family suffer from various allergies, and many suspect there may be at least some link to not being exposed to enough allergens at an early age (father was a surgeon and our home was always clean – nearly to the level of an O.R.).

I do this with a cheap (~$20) USB RTL-SDR – no Arduino or custom electronics necessary. Of course, I only use it to monitor my own energy usage (electricity and gas) using rtlamr[1] and a script that periodically sends the data to InfluxDB, then displayed using Grafana.

The result is a smart home energy monitor that doesn't require any clamps near the electrical panel, and it exactly matches the usage for which I'll be billed.

[1] https://github.com/bemasher/rtlamr

> ...just a few years ago, the only legal way to fly a drone was with an actual aircraft pilot’s license.

As I understood it, small unmanned aircraft flown for hobby or recreational use had long been excluded from the full authority of the FAA (except for some basic rules for respecting the airspace of manned aircraft), or the need for a pilot's license. They were essentially treated like RC airplanes, which of course have not required a pilot's license to operate, albeit with some of those basic rules (I believe the AMA was involved in establishing some of those guidelines).

Of course, when drones became more popular, there was a lot of misunderstanding when it came to the interpretation of current regulations (e.g., line-of-sight operation vs FPV), and it was debatable whether or not the FAA even had the authority to regulate the operation of small hobby aircraft, including drones. Commercial operation was and still is clearly regulated by the FAA and requires a license.

Basically, what I'm saying is that in this category of aircraft (for recreational use), the FAA has become more involved and restrictive over the past few years, not less so. In my opinion, that's generally been a good thing (some people do foolish things with drones), but the regulation should also be balanced in maintaining some of those reasonable freedoms of operation.

Agreed. One of the things (among many) that convinced me of IG/FB's hostility toward developers – and users – was when they stopped providing basic user information in their official "Instagram Basic Display" API, which according to their docs "allows users of your app to get basic profile information, photos, and videos". This is literally the full list of fields you can get for a user's profile:

account_type, id, media_count, username

Can you get the user's name? Nope. Bio? Nope. Follower count? Nope. Website? Nope. Pretty close to nothing.

This is all publicly visible information by the way (so no, it isn't a matter of protecting privacy), and I'm not even talking about getting it for users who are followers/followed by the person who authorized the app; you can't even get the authenticated user's own info. It's absolutely ridiculous, and any attempts to fetch that info from the website via automated means gets severely throttled or shut down almost instantly.

I will never build anything else that even remotely relies on an existing social network for an important function.

That's true. I suppose keeping track another way might offset the added annoyance of the "rewind" routine (attaching another device, connecting USB for power) when refilling the reservoirs. Personal preference I guess.

Nicely done! Instead of a device to rewind/reset the counter in the EEPROM periodically, I wonder how hard it would be to modify or replace the EEPROM with something that simply ignores any modification to the data (essentially making it read-only). That way, the machine thinks it's decrementing the counter each time, but it always remains full. There'd be no need for a software reset.

Still doesn't make sense to me.

> If they add their brick to the top, other students will pay them (in bricks) to write their own names on it with a sharpie

Other students are paying in bricks? Is that supposed to be transaction fees, mining (that's the sudoku puzzles), or what? And is there any indication that a name on a brick means anything (or can be exchanged for anything)? Is there a limit to the number of names on bricks? Can those names be verified at any instant, anywhere in the world with near 100% confidence?

I know it's a simplification for the purpose of making a point; it's just that the point becomes invalid when the simplification throws out the central characteristics of the thing that's being represented.

I'm not sure I see how this relates to cryptocurrency. It misses the core attributes that give crypto value: scarcity, and the fact that it can be exchanged for other things of value.

If there's no shortage of bricks, and those bricks can't be used (or exchanged) for anything other than the material for making the tower taller, then of course that would be pointless.

But that's not how cryptocurrency works. The whole purpose of proof-of-work is to protect the attribute of scarcity in a distributed way where one actor can't control (or change) the rules.

> Do you trust Amazon, Google and Microsoft or millions of sysadmins in podunk companies to secure their infrastructure?

Of course not, and when they screw up, we lean on a robust (yet imperfect) legal system to intervene.

One of the advertised features of smart contracts is a reduced dependency on trust, so if they don't actually have that advantage (at least in relation to real-life interactions), then it's hard to say they're any better than traditional legal contracts for those use cases.

Cool - glad you brought up the smart lock example. How does that work without trusting (presumably off-chain) software/firmware to honor the change as to who should be able to open the lock? The smart contract might be iron-clad in showing who should have access, but at some point, that has to be interpreted and executed by a real-world entity, human or machine.

In other words, standard contracts work just fine (without any lawyers involved) when everything goes to plan. It's the failure cases that matter, and it's not hard to imagine a compromised lock (or an entire company's locks if they're connected to the internet for access to the blockchain) that no longer respect the smart contract. So you're back to calling your lawyer to help sort out the mess.

Wouldn't that just make those few oracles an increasingly valuable target for manipulation/corruption?

I'm not sure I've gotten a clear answer to this before, so someone please help me understand:

I can see how smart contracts might be useful in contracts that involve other assets that are directly connected in the same decentralized context (i.e., other bitcoin transactions or blockchain entities).

However, for anything else in the real world, they always (from what I've seen) require an "oracle" of some kind. True, that can be based on a consensus algorithm involving multiple parties in the real world, but it always ends up requiring trust that those real-world entities are playing by the rules. If we're relying on the good faith of real-world entities, how is a smart contract any better than a legal contract (a human would have to step in as the arbiter in either case)?

Correct me if I'm wrong, but this code would block if (for example) one single request in a batch of 10 takes significantly longer to complete. The 9 other threads are then doing nothing while they wait.

Of course, you could implement a more robust algorithm for scheduling threads, but it sounds like an implementation of FiberScheduler would make the best use of a single thread's resources (and you could scale that to multiple threads as needed using something like a shared queue). Since fibers are lighter-weight, it's presumably more efficient to run parallel IO operations in a single thread, and only use more threads if your work requires it.

Is this the "new magic" that DHH teased on Twitter, or are we still waiting to see what that is? Also, should we expect this to be included in a future version of Rails?

My first impression is that the API seems a little convoluted, but that might just be me. In an ideal world, I'd love to just build components (similar to React components) on the server side, and let the framework intelligently handle synchronizing state over the network (Phoenix LiveView seems closer to that), but this feels like it involves a lot more framework-specific logic (and markup) with special cases - stuff that's likely to change as the framework evolves, so I'm not sure how I feel about it.

I guess it makes sense in terms of making this easier to add to an existing rails app incrementally (since it's more-or-less "opt-in" for each model, view, and controller), but if I'm building a new project with this and want it on everything, it feels like it will necessitate a lot of code duplication. Either that, or I use it judiciously only when absolutely needed (and use traditional rails behavior for everything else), but that feels like a mess of two very different approaches bundled together in one codebase.

Exactly what I was thinking. It doesn't even really help to run your own proxy on a server somewhere, because although the target wouldn't know for sure what the client's IP address is, queries from just one IP are likely to be easily correlated (statistically or otherwise).

So you convince some neighbors to use your proxy... As the number of clients grows, so does the uncertainty that the person running the proxy isn't colluding with the target, so you're back to the same trust issue that you were trying to solve in the first place.

This may have changed, but in the past, I believe they were essentially just rebranded Xiaomi cameras (possibly from other suppliers) with different firmware. I originally thought the Chinese products were clones of Wyze, but it appears Wyze is actually just using existing low-cost hardware from overseas. Happy to be corrected if I'm wrong though.

FYI - for some camera models (Xiaomi or Wyze), you can flash them with this custom firmware[1], allowing for a lot more customization.

[1] https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks

Your reading of "its not 'run any container in Lambda'" may be a bit too pessimistic. From what I'm seeing, you can run any container (<10 GB), but it just has to implement the Lambda Runtime API[1]. You can't run a random container and expect Lambda to know how it should communicate with the world.

As others have noted, ECS or Fargate would be more appropriate for cases that fall outside the Lambda event model.

[1] https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.ht...

Not a dumb question! I'm sure there are a lot of different approaches that could work.

For my own projects, I like to keep client-side code separated from the server-side code. The static site (with compiled JavaScript) gets deployed to S3/CloudFront, while the Sinatra API is packaged as a Docker image and deployed to ECS (or any container service)[1]. This means that Sinatra is only handling the API requests, and all of the markup, JavaScript, and other assets are served from a CDN.

[1] For this to work, you'll likely need to set up CORS on the server side, but that's well-supported now and fairly simple to set up.

I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe.

In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated, which is part of what makes it great, but to be more opinionated on JS in the past probably would have been detrimental to the Rails community. I've felt the pain in my own work: every 2 weeks, it feels like my webpack/react/babel/etc toolchain and codebase need to be refactored because what was recently best-practice is now considered "legacy" and unsupported. When you embrace a specific set of technologies, you take on a certain amount of risk that those technologies will be deprecated, unsupported, or unpopular tomorrow.

I believe (hope is probably the better word) the JS landscape is getting more mature and stable, and it makes sense that the recent versions of Rails have incorporated more of what has become "standard" JS tooling. I'll always love Ruby, and even if I don't use Rails at the moment, I appreciate what Rails is doing and I directly benefit from the contributions of the Rails community.

More recently, I've been trying to learn some Elixir (those Phoenix LiveView demos look amazing), but not sure I'm ready to jump in 100%. Looks like matestack is essentially doing something similar with Ruby, so I'll be interested to see where it goes.

If you haven't already seen it, I'd recommend watching Thirty Two Short Films About Glenn Gould. I'm not familiar enough with Gould's life to comment as to its accuracy as a biopic, but the film is definitely unique and interesting, painting a non-linear mosaic of his accomplishments, quirkiness, and genius.

I'm not a lawyer, and I definitely think the whole copyright system needs reform, but I believe there could be legitimate issues with the legality of publicly posting guitar covers as this person is doing on their channel.

I'm not very familiar with the channel, but from the little I've seen, I believe the educational nature (and thereby fair use defense) could be debatable. Even if some of his videos are clearly educational, it seems that some videos are just covers of popular songs. And even if he's not using published sheet music to play the songs, he may still be required to have mechanical licenses, and possibly also sync licenses.

Most published music has three licenses that could be relevant here: the mechanical license (covering the combination of notes, rhythms, and/or lyrics that make the song distinct and "recognizable"), the sync license (using the song along with images/video), and a master license (covering a specific recording of the song). From my limited experience (and confirmed here [1]), it appears that many of these videos probably require at least a mechanical license to be performed publicly on the channel.

That being said, I absolutely agree with the sentiment that YouTube's handling of these issues is extremely problematic. They really need to start treating content creators with more respect and assume innocence until proven otherwise. There also needs to be more transparency into the process (and claims) so creators aren't left in the dark, along with improved ways to respond to erroneous claims.

[1] https://www.legalzoom.com/articles/posting-cover-songs-on-yo...

I'm familiar with how residuals work (and sometimes go unpaid), but in my opinion that's not a flaw in the idea itself, but rather a question of regulation and/or better legal work (in the contracts) to prevent studios from exploiting loopholes.

Earlier in my career, I was the victim of similar shenanigans when it came to startup equity (promises of equity that never materialized), so it's not like the traditional path to IPO precludes deception and exploitation. My point is, with proper legal boundaries, a system of compensation with increased transparency is fairer than the current one that essentially uses a startup lottery to attract employees.