viernullvier

> I don't think it has the ability to select arbitrary edges and apply such features (I could be wrong).

That's actually how it works. Chamfers and fillets are handled by OpenCascade, so they can be applied to arbitrary edges. They only exist on the solid model though, so they are not integrated with the solver.

I'd be curious to see how native chamfers/fillets in solvespace would work, I imagine some amazing things could be done if they'd be part of the solver.

None, at least not deliberately. Previous attempts at vibe-coded contributions have been politely rejected.

Source: I am one of the contributors.

I've seen commercial products that use socketed devboards inside. If anything, it's just an indication that the hobbyist and professional spaces are slowly converging.

Please be aware that this is not a first-party open source release of a previously secret internal spec/implementation, but rather the result of an impressive reverse-engineering effort by Christian Nöding, whose videos about this project have been posted on here as well. Still, minor kudos to Behringer for giving the official permission and sharing some internals to make this possible.

There is, actually, but in a different context. The `adb sideload` command allows you to boot a device from an image without flashing it.

For the METR rating (first half of the article), it is indeed 50% success rate at completing the task. The win rate only applies to the GDPval rating (second half of the article).

It's because the default "analog output" PWM mode of a microcontroller will only give a rough approximation of the signal that the servo actually requires. For a servo, the duty cycle is (almost) irrelevant, the 0-100% scale has no meaning here. What matters is the actual length of the control pulses in milliseconds - the gaps between them can be arbitrarily long within a certain range.

If you think about it, it actually makes a tiny bit of sense. First, it is failsafe: Breaking the control line or shorting it to ground will not move the servo to 0%, shorting it to signal level will not move it to 100% - it just doesn't move at all and stops applying force. Any sentient being within the movement range will definitely prefer it that way instead of random movements. Second, it can actually be pretty precise: The driver circuit can be completely analog, it doesn't have to be limited by arbitrary digital quantization steps. All it needs to do is check if the current encoder value is above or below the target and apply power to the motor accordingly.

There have never been any grid-scale nuclear power plants in the state of Berlin. I don't see how this statement relates to the prior discussion in any way other than vague geographic proximity.

In this specific case, they started digging through a HDD image that someone else pulled. They're still trying to get hold of an actual Redbox machine to investigate the hardware as well.

Would it be possible (in theory) to build a receiver on an embedded platform, for instance an audio-only ESP32 speaker, or is there something in the protocol that requires a more powerful device?

Fun fact: 400V 3-phase and 3x 230V are the very same thing. You'll get 230V AC between Neutral and each of the three phases, but the AC voltage between two of the phases will actually be 400V.

You can also swap primary and secondary clicks (at least in the Android version), which makes it the fastest on touchscreens as well.

This was one of the first games I installed on my very first Android phone, the Motorola Milestone. 15 years later, I'm still playing it nearly every day.

I'm a bit disappointed though that the original desktop version doesn't really play nicely on touchscreens.

I have to vehemently disagree with you here - the Android version is the main reason why I needed to set a "no phone in the bedroom" rule for myself.

Wait, so no one has been looking at the RUM data for three entire months? Why has it been there in the first place then?

For inkjet technology, it's the print head. Fundamentally, an inkjet printer works similar to a plotter, laser engraver, FDM 3D printer, or CNC router: There's a mechanism that accurately places the tool head at the desired X and Y position in order to do its business [0]. This part is a solved problem, there are many open-source reference designs to draw from.

For a printer, the devil is in the details though - quite literally: A printer needs to place tiny ink dots on the work piece in a fast, accurate, predictable, and repeatable manner. Placing just one single dot at a time would be prohibitively slow, so the print head needs an array of tiny nozzles in order to print multiple rows in one pass. The design also needs to ensure a consistent (and adjustable) dot size across all nozzles regardless of the ink level.

Designing and manufacturing such a print head is extremely complicated (if not impossible) for a hobbyist, and as of today there is no vendor-agnostic third-party design you can just buy off the shelf. The only forays into DIY printers are either rudimentary low-res single-nozzle designs [1], fully repurposing existing printer hardware [2], or reverse-engineering proprietary ink cartridges that come with a built-in print head [3].

[0] Technically, this is not entirely correct because a typical printer's Y axis is a rotating drum that transports the paper instead of a linear axis. Also, a printer's X axis is usually equipped with an encoder ribbon that allows for far more accurate positioning compared to the classic open-loop stepper motor systems used in many open-source designs.

[1] Example: https://hackaday.io/project/167446-diy-inkjet-printer

[2] Example: https://www.youtube.com/watch?v=_VP8ORq2al8

[3] Example: https://ytec3d.com/hp45-inkjet-printhead/

Please don't give them ideas.

OTOH, I've already stopped posting and commenting and will only resume once they change their stance on moderation tools and third-party access. If old.reddit goes for good, I'll go as well.

I heard from a mod of a large sub that old.reddit is not going anywhere - apparently all of the admin tools are built on old.reddit, so shutting it down would not be feasible without a huge engineering effort.

Your calculation is way off. Getting 8kWh a day from a single 400Wp panel would already require 20 hours of operation at theoretical peak power, so under real-life conditions you can only expect a fraction of that per day.

This doesn't invalidate your point though - even if you're one order of magnitude off, your £200 solar panel will buy you about ten times its price worth of electricity.

Those estimates are unrealistic regardless of any potential degrowth scenario. You'll run out of drivers and/or roads way before the 100 year mark.

This also implies that a future generation social protocol with three "@" symbols will only take 7.5 years to become mainstream.

Thermal storage, for instance: https://en.wikipedia.org/wiki/Thermal_energy_storage

> Somehow, writing the exact same structured text that would go into a blog post in a thousand tweets is different?

It's a very bold assumption to expect the exact same structure in a blog post (which can be edited at arbitrary places within the entire document) than in a twitter thread (where tweets can not be edited once sent). Editing - or not being able to edit, for that matter - has a massive influence on the eventual resulting text.

In fact, the incremental nature of twitter threads kind of caters to the ADHD brain because it completely defeats self-sabotaging perfectionism by removing the opportunity to revisit and rework previous sections of the text. If you follow Foone for a while, you'll see that they tweet their thoughts and works as it happens. They don't sit down and prepare the entire thread beforehand because doing so would make it a lot harder to finish, if not entirely impossible.

About eight years ago:

https://en.wikipedia.org/wiki/Annexation_of_Crimea_by_the_Ru...

As others said, conventional EVSEs are just spiced-up power switches, so there's not much to gain from SiC. It does however open up a pathway to smaller / cheaper / more efficient residential DC fast chargers which can also enable a widespread rollout of V2G.

Or maybe not. It's not the weight of the fuel cell/motor combo that is the limiting factor, but the weight of the H2 storage tanks. An H2 jet engine will probably [0] be less efficient than a fuel cell + motor, so more H2 storage is required in order to reach a comparable performance.

[0] Considering the Carnot efficiency of a jet engine at ~30%, a combination of fuel cell (~60%), motor (~95%) and propeller (~80%) will still beat it by a factor of 1.5.

This looks like a solution in search of a problem. Hydrogen combustion will never reach the efficiency of current off-the-shelf fuel cells, let alone potential future improvements on fuel cells; battery-level efficiency is completely out of the question. There is no use case for choosing combustion instead of fuel cells, period. Hydrogen combustion introduces additional problems like NOx emissions that simply don't exist for fuel cells. Aside from maybe material science, there are no further insights to be gained here that would be applicable in any real-world scenario/product.

> But using a hydrogen engine rather than fuel cells would have certain advantages. Such vehicles would employ conventional engine technology and provide a driving experience similar to gasoline cars. And "it's easy to generate torque at low rpms, making it ideal for trucks," a Toyota executive said.

None of these are advantages, it's rather the opposite of an advantage. Electric motors provide consistent torque from zero to maximum RPM and don't need sophisticated transmissions. On top of that, hydrogen engines don't work particularly well with variable loads (the same goes for fuel cells, but this can be mitigated by a buffer battery).

Fun fact: Toyota's car isn't even the first hydrogen-powered car to complete a 24h race. In 2013, a modified Aston Martin Rapide S equipped with a dual-fuel petrol/hydrogen system completed the 24 Hours of Nürburgring.

Not in its current iteration. The biggest advantage of natural gas generators is the possibility to ramp them up and down quickly, making them an ideal choice for peaker plants or load following. For nuclear, on the other hand, the options for throttling the output are quite limited - both physically and economically.

As a mitigation, combining them with battery storage would be an option, but then again it would still be cheaper to use wind or solar instead of nuclear as the source of energy.

Here are the raw electricity production figures for the timeframe considered in the study:

https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE...

When comparing the year-by-year differences, a few interesting things turn up. For the sake of simplicity, I've only counted wind and solar as renewables and natural gas + black coal + lignite as fossil fuels.

- There have only been two years where a reduction in nuclear was not (over-)compensated by an increase in renewables: 2010/2011 (nuclear -30,8 TWh, renewables +19,3 TWh) and 2015/2016 (nuclear -6,8 TWh, renewables -1,3 TWh).

- Even in 2010/2011, the increase in renewables overcompensated the reduction in fossil fuels (-2,8 TWh)

- There have only been two years which actually saw an increase in fossil-fuelled electricity production: 2011/2012 (+7,2 TWh, still fully compensated by renewables) and 2015/2016 (+5,5 TWh).

- In the entire timeframe (EoY 2010 to EoY 2017), renewable production increased by +94,9 TWh, which is more than the reduction in nuclear (-60,8 TWh) and fossil fuels (-28,5 TWh) combined.

- There've been some internal shifts happening within the fossil cluster. In the first couple of years, natural gas consumption was dialled back in favour of solid fuels, which was then slightly reverted in the later years. This is also the reason why 2015/2016 did not see a catastrophic increase in CO2 emissions - parts of the worst offenders have just been replaced by natural gas.

I'm still not sure how the study reached a conclusion that is kind of contradicting real-world data.