Just for completeness: For reproducable builds F-Droid can now distribute builds signed by the developer.
1,136 karma · joined April 2, 2020
It is, but (as far as I understood it), they're using ARM SWD IP (which is a fine choice). But since their connection between the SWD IP and RISC-V DM is custom, you're going to need your adjust your debug probe software quite a bit more than between different Cortex MCUs.
Other vendors with similar issues (for example WCH) build something similar but incompatible, requiring their own debug probe. This is a solved problem for ARM cortex.
Meanwhile the RISC-V spec only defines very basic interrupt functionality, with most MCU vendors adding different external interrupt controllers or changing their cores to more closely follow the faster Cortex-M style, where the core itself handles stashing/unstashing registers, exit of interrupt handler on ret, vectoring for external interrupts, ... .
The low knowledge/priority of embedded of RISC-V can be seen in how long it took to specify an extension tha only includes multiplication, not division.
Especially for smaller MCUs the debug situation is unfortunate: In ARM-World you can use any CMSIS-DAP debug probe to debug different MCUs over SWD. RISC-V MCUs either have JTAG or a custom pin-reduced variant (as 4 pins for debugging is quite a lot) which is usually only supported by very few debug probes.
RISC-V just standardizes a whole lot less (and not sensibly for small embedded) than ARM.
To me it feels like OSMAnd heavily prioritizes feature develompent over performance, which is fair enough but still annoying.
Yes, this is what the constitutional court decided.
> If some party is illegal for whatever reason, it should be banned right away.
It should be hard (and is very hard) to ban a party. Thus if every party illegal should be banned right away, a large amount of effort would need to go into banning by the highest legislative and judicial bodies in the nation. It's furthermore quite hard to definitively establish a party as such, which further makes such things much slower (calls to ban the AfD have been happening for more than a decade now).
A court can only ban them after the parliament has voted to ban them. One of the hurdles on getting the parliament to vote on this topic has been the outstanding decision by this body, if it's really "gesichert rechtsextrem". At least in many previous cases surrounding this question (mostly libel cases), courts have argued that the specific people these cases were about could be seen as "outside of the democratic spectrum".
> The measures would of course need to be biased toward false-postives to prevent future false negatives.
Certainly, that's why both the parliament and the highest court have to decide, with previous instances sometimes not coming through (for example, the NPD for not being relevant even though they were certainly Nazis).
> That the afd growth of doubling their power since last election and AFD is now polling in first place. So to win the next election they need to essentially remove AFD from being an option; or los
There would be no reason to ban a party if they could be ignored (see the NPD), you only need to ban extreme parties if they're popular. If the AfD were at 3% this would be a much smaller topic, since there would be no foreseeable risk. But even with the AfD at much lower than <15%, this was very much an area of concern, with steady (legal, as with this classification and previous ones concerning subgroups) progress towards establishing their extremist status.
But hydrogen fuel cells are also expensive to maintain and have been a huge maintenance burden, as they're quick to fail with contamination (and lots of other factors), leading to hydrogen trains being replaced by diesel trains.
Hydrogen can be clean, but it isn't and won't be for the forseeable future for the simple fact that it would be way to expensive. Almost all hydrogen today is made from natural gas and much less efficient than powering an electric car from a gas plant. But even if hydrogen was produced with electricity, due to the low efficiency it would be much dirtier than an electric car (And we're entirely discounting hydrogen leakage, which is much more potent at heating up the planet than CO2).
Hydrogen can also be fast to refuel, but it takes much longer than gas and often requires a long "time-out" after the last refueling. Hydrogen fuel stations are also very unreliable. With current EVs, 20%-80% charging in 20 minutes is state of the art, which should make charging times mostly a non-issue when this is also available in most "cheap" EVs.
Many other aspects of healthcare follow a similar model, where parts are fully private, parts are non-government-but-quite-close-in-function (Ärztekammern and other things) and many to most are public in some sense.
We need to do that (and even that is proving very hard, looking at the issues building out electrified ground transport and electrifying heating) and it will help a lot, but it won't be enough.
We have quite a few sectors where (economic or even feasible) non-carbon solutions aren't very forthcoming: Especially in (animal-based) food and aviation, but also manufacturing of e.g. new steel or concrete. These account for a huge chunk of emissions and reducing their emissions close to 0 in the next 20 years doesn't seem very likely. Looking at other technologies that are currently economically viable, such as solar, wind, electric cars or LED lighting, 20 years for nearly full adoption is very optimistic.
Reducing emissions there will mean also reducing consumption (and thus production, or the other way around) of those products. If we only accept superior technology as a means to "solve" climate change, we won't.
That'll very likely not mean degrowth as a whole as many sectors of the economy, especially the growing ones, are very compatible with an "electrify-everything" approach.
Interfacing with the peripheral registers themselves is also a bit simpler with Rust in my experience, as a proper .svd already contains bitfield setups with enums and R/RW/W1 information to at least set the bits you want instead of the Macro-Hell in C some manufacturers throw at you.
It's also news to me that the UK was ever self sufficient for energy in the last few decades. Most countries are at least roughly matching their electricity production, but almost all are huge energy importers for non-electric energy, so I don't quite see the issue (if e.g. most large oil producing countries were to suddenly stop exports, most of the world would be in huge trouble).
Why do you claim that this, which has been the reality for almost all countries over the last few decades, would be horrific?
The CH32V003 is $.10-$.20, quite usable in my experience and features a 16 kB ROM, 2 kB RAM and a 32-bit 48 MHz RISC-V.
The PMS150 is available for <$.05 with ~1.5 kB ROM, 60 B RAM and an 8-bit 8 MHz CPU.
If you're excluding chinese manufacturers, the STM32G030 is sub-$.80 in quantity for 32 kBs of ROM, 8 kBs of RAM and a 32-bit 64 MHz ARM CPU.
I doubt most users will, even when given the link to an .apk, install it. Either because they are discouraged by the alarming prompts (in my opinion a tradeoff that is unfortunately worth it) or because they get lost.
Yes, and it also contains other IP block (for example the USB from Synopsys) for which fees will be paid by the manufacturer. The Cortex-M0+ cores in the rp2040 are probably pretty cheap, so they don't impact the final price much.
> is there a derivative or version of this chip without the ARM core?
No. There might be future versions (they are, in general, looking at Risc-V stuff), but there isn't too much benefit.
> That said, this is the same issue if there are MPEG codecs [..]
No it isn't. The issue with those is that not only does the creator of the IP block itself need to get paid, but also the patent pool behind it, which is usually much more expensive. For most products from a smaller company (and even many larger ones), an AV1 hardware codec or a DisplayPort output will also be an IP block bought from someone else.
No, they don't. There are a handful of weird french systems (and even less outside of France), but there are more ruber-tire metros than trams, I'm sure. They are rare and have been getting rarer.
80m is in the lower half for metros, but long in the context of systems having on-street portions (exceeding the german legal limit of 75m with a special exception). It's also on the long end for small metro systems.
I find this really interesting that is seems to be the limit for "big-boy" complicated subway systems, while there are many very complicated smaller systems that achieve much more. For example, a lot of the german Stadtbahn systems run somewhat long trains (up to 80m), run using conventional signalling systems underground (so not on-sight, which would allow for a much higher throughput). Naively I'd assume the tram-style segments and frequent at-grade crossings would make this much worse, but apparently not.
For example, Stuttgart (https://download.vvs.de/Stadtbahn_Liniennetz.pdf, https://gleisplanweb.eu/show.php?Map=Stuttgart&Index=1&Heigh...) currently runs 27 tph between Stadtbibliothek and Olgaeck, with plans to run 30 tph without any upgrades, and 30 tph between Staatsgalerie and Stöckach (additionally even running the U11 for events) without any significant issues and quite a complex network with many flat junctions outside the underground sections. The DC Metro has much less complicated branching/reverse-branching patterns.
I have only implement touch buttons for hobby projects using a different MCU, but is there a reason to not just use the PIOs for touch sensing?
- There are many less people (probably 2-3 orders of magnitude) accessing the data at all at Google, and (probably?) most sensitive data isn't accessible at all
- As you can't choose to avoid the government, the standard of trust should be much higher
- I don't know how well it works at Google. The reports of videogame leaks through employees accessing accessing unreleased Videos and the (for now) inability from Google to solve this problem at least indicates to me that the approach has issues.
- There are many more valid reasons for a government employee to access the data, so it's harder do differentiate. You also have the issues of police dempartments (and similar), where an access might not be allowed but done as unoffical policy "for the greater good"
- I would think that Google is much more capable of implementing and managing such a system than goverment suppliers or agencies, unfortunately
It's also silly to use batteries as base load, as is the concept of base load in general in combination of cheap, but non-dispatchable, renwables, which is one of the things that hurts the economics of nuclear plants.
Anecdotally, in germany, projects to (re-)build trams in cities often fail over local protests, while rail reactivations don't usually succumb to that. HSR does get a lot of local protests, but (IMHO) not really because of the noise and fails less often compared to trams.