Hacker News new | past | comments | ask | show | jobs | submit | more Findecanor's comments login

Carbon capture technology is for installation inside chimney stacks, when there is no alternative to burning stuff and thus producing CO₂.

Nothing else.

You'd extract the CO₂ directly from the exhaust gases. It can't clean CO₂ from the open air. It does not scale that way.


The more you look into it, the more you realize we are already doing this, kind of. Then you realize that the real low hanging fruit is sort of in other areas, sulfur dioxide, methane capture, particulate, and especially home heating. European wood pellet and home wood burning stove users, I'm looking at you.


6502 is a bit limited, so you'd have to resort to self-modifying code to get things done — and self-modifying code is a big no-no on any processor with cache, and therefore not a good habit to acquire.

For teaching, I would instead go with RISC-V. In particular RISC-V with the bitmanip extensions, which make some things much easier and gives it feature-parity with the base set on x86 and ARM. The Raspberry Pico 2 has two RISC-V CPUs with those. The board is easy to use, widely available and has a lot of support. There are also alternative boards with the same MCU but other form factors and features.


I got a tiny bit offended by the assumption that I'd rather have an Apple Watch.

I'd think the ideal for me would instead be something in-between a Pebble and a Sensor Watch. Something hackable with more battery life, that is a watch first (and a smartphone notification screen never). I wonder how far I could go towards that goal with the upcoming Pebble hardware and rewriting the OS kernel to sleep more.


I interpreted it as an intentional insult :)


In legal terms, that is not entirely correct. In practice, it is however. For now.

EU (which is not the whole of Europe) has regulation that allows a copyright owner to opt out of data mining for AI training. But the framework is incomplete: there does not exist a generally agree-upon method to actually opt out. There are a few protocols and file formats from a couple of organisation but none which has been given any official status. While a publisher may use one, a web scraper might support only another.

Japan has traditionally been quite strict on copyright law. I would not be surprised if the law would get tightened to explicitly disallow AI training on copyrighted works.


The disagreement is not about what is, but what should.


I'm seeing a lot of prevarication between the two, and a lot of taking for granted of even the existence of copyright, despite the it being a modern creation entirely of positive law.


I used to be a fan of Star Wars. Then Disney bought the franchise, and transformed it into something that a large number of fans, including me, did not like.

That the old movies exist* does not redeem the current franchise for me.

*: albeit in reality the original films are being preserved by fans and not by the official rights holder.


It's all relative. I thought Lucas let Star Wars wither for too long, extended universe not withstanding. Most of the Disney works based on it have pleased my family and I.


One simple but genius detail about the Atari ST's case design is that the case screws on the bottom have square holes while other screws have round holes. You don't have to learn beforehand which screws are which, or risk loosening things inside that you didn't intend to.


BankID scams in Sweden worked because it did not require there to be authentication between the device that logged in and the device that authorised the login.

The victim got a phone call in which the she got manipulated into authorising something in the BankID smartphone app. But what she was actually doing was authorising the attacker to log into her online bank account.

First after several years (of blaming the thousands of victims for their millions lost) did the system start using QR codes on the screen scanned by the smartphone.


The title makes it sound as if RISC-V is a liability. The liability lies in it being possible to reactivate cores that were supposed to have been permanently disabled.


The RISC-V implementation on RP2350 does not have any security features - it has no business to be on silicon that was supposed to be marketed for security features, but it is there. Then there are bits to disable ARM and/or RV cores, but disabling the ARM core takes priority over disabling insecure RV core - these are human decisions not architectural.

This isn't about the technology - the organization's priorities are clearly divided between two segments - one that's trying to expand the revenue by expanding into enterprise/commercial market and another that is trying to stick-on cool stuff and prioritizing fun. In this case neither won - the fun guys got kneecapped by the E9 bug making this silicon unusable for hobbyist projects, and the fun stuff kneecapped the enterprise stuff by bypassing the security bit.

(as you can imaging, I'm extremely disappointed with RP2350 - RPi needs to focus or they hobby/maker market is done)


If the RISC-V cores were removed, the bit assignment for the critical OTP flags would be different. Quite likely this attack would then have directly enabled Secure debug access to the Arm cores.

Whoever wrote that headline lacked even a cursory understanding of the attack. You can do better by watching Aedan Cullen's excellent 38C3 presentation for yourself.


It seems a product that sells for $7 pushes security validation all the way to the right - the customers.


The RISC-V cores are innocent accomplices. Having a mix of cores with and without secure boot gives attackers more tool to play with. The exploit works because if both sets of cores are "permanently" disabled the hardware state machine instead of bricking the chip starts the RISC-V cores. Just defaulting to the ARM cores would've prevented this exploit from working.

It also looks like the chip designers didn't know about the read-persistence between the validation pattern reads and the actual configuration reads achievable by glitching only the OTP memory block (the USB peripheral isn't enabled at this stage). Without access to the documentation for the OTP memory block we can only guess who deserves the most of the blame for this oversight.


There has always been a wireless version of the above-mentioned Kinesis Advantage 360, also running the ZMK firmware.

Before it, there were the open-source Dactyl variants that more or less copied the Kinesis. The original Dactyl [1] (2015) has a layout like the Kinesis but the more popular Dactyl Manuform variants have different thumb clusters. And people have been building them both with wired and wireless controllers.

The history is not complete without mentioning that Kinesis (Model 100 in 1992) in turn had copied the Maltron [2], designed by Lilian Malt in the 1970's.

1. https://github.com/adereth/dactyl-keyboard

2. https://www.maltron.com/maltron-history.html


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: