Unless you are on foot (and even then) the route needs to follow existing roads, you can only zig zag as much as existing roads do it not endlessly.
And almost any practical routing system will have a mechanism for tradeoffs of different aspects. Often there is a distance/time tradeoff which directly relates to speed on corresponding segments. But the tradeoff can also be in the form of "on average x seconds spent waiting green light in each intersection or time to stop before railroad crossing. So there is no reason for a system optimizing grade to completely ignore all other factors, it's just a question of weights and curves of each of them.
Isn't sha1-dc just checking for a small list of hard coded disturbance vectors? Meaning that script kiddies can't easily reuse exact values that researchers spent a bunch of time precomputing. That's far from being a good long term solution.
I'm not an expert on this but my impression is its a bit in the middle. It isn't a great long term solution, but finding new disturbance vectors is very hard. Its not like someone can just go find more on a whim.
I would say biggest issue with licensing comes from clear attribution being problematic at the scale of OSM not the virality or relicensing problems. That and OSM aiming for being squeaky clean, far away from any ambiguity in terms of third party data licensing.
It is simply impractical to attribute all the sources anywhere in UI or printed copies of map. And whether an attribution hidden somewhere deep in wiki is considered acceptable is grey zone.
The fact that OSM themselves want attributions is another reasons why they have high standards for what's considered an attribution which they can't achieve for third party data sources.
In case of software License.txt and Help/About is considered standard practices. But that doesn't necessarily translate to other mediums of copyrighted work. Something like books or research papers have their own generally accepted practices of how attributions are handled. For maps digital and physical text in the corner is often used practice. You can see it even for something like a building plan posted next to construction site, listing additional map sources used for preparing the drawing. So it's not exactly unique invention by OSM. Back to comparison with software, software can't exactly be printed out so the concerns about attribution are different. Also software licenses typically require listing including a copy of license text not just attribution , which is simply impossible outside separate file or dedicated UI.
In practice the OSM aiming for better than good and thousands of unverified contributors being uncontrollable lands it somewhere in the middle. But if they aimed for barely acceptable all the contributors would definitely push the bar bellow legally acceptable.
On the topic of government data, CC-BY is also common which is somewhat problematic. But more often they have no idea under what license they are releasing their data. They come up with complicated schemes of metadata, which never gets properly filled or parsed, thus resulting in conflicting information about license being used. And if you ask them to clarify they will just say, "yes yes it's open data you can reuse it", with the government employee having no understanding about differences between various licenses and that not all open data is equal.
I understand that there is precedent and there is a logic to it... but to me it rubs me the wrong way. I think text and code are not very analogous situations. If I think in terms of software licenses..:
- I sort of respect the copyleft ethos. You put out a thing with the understand everything it touches is also going to be openly available. I think attribution isn't really part of the central idea there.
- I also respect the MIT/BSD style thing where you're just putting stuff out there in the public domain and it's part of the corpus of human knowledge. You leave your mark so to speak.
The middle ground of "You can use this but you gotta promote our service and stamp our name on it" just feels icky. I don't want to contribute to that. I feel I'm helping OSM the organization and.. I don't know them .. are they good stewards of the data I'm giving them? Are they going to be good stewards in 10 years? Hopefully that kinda makes sense? I guess the same can be said for Wikipedia, but Wikipedia for better or worse is very siloed. You have to attribute stuff you copy from Wiki but ..
A: Realistically nobody is actually copying wiki articles other than lazy high school students. It's just not very reusable outside of Wikipedia
B: This is more of a plagiarism issue. It encourages people to disclose it's not their own words (this is not an issue with maps.. nobody thinks you surveyed your city to draw the map)
If Wiki became CC0 tomorrow nothing would really change. If you needed to fork Wiki and put an attribution in the footer, it'd be very innocuous..
I don't get why you consider MIT/BSD fine when both of them have "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." but when OSM does the same it somehow becomes "you gotta promote our service".
Might not be so bad considering that all the plastic is on opposite side of fiberglass board. When desoldering connectors or smd chips, it's often hard to avoid directly blowing hot air at the plastic bits. That's not the case here. Having dots grouped in rows of 7 makes things a bit more challenging. As it means heating up larger area and increase chance of them getting stuck even when all the solder is molten.
But the theory would have to be tested and there aren't many people with so much flipdot panels that desoldering is a major concern. And ones who have few some don't want to risk it. So bulk processing techniques are likely underexplored.
Isn't multiple floors of bookshelves with open central area a very common theme in large fancy libraries? For example British museum reading room, Oval room in France national library, Morgan Library & Museum, Rose reading room in New York Public Library.
The shelves can't be very high to keep them easily accessible, adding additional levels solves that. Open central area with higher ceiling gives more natural lighting.
It doesn't really say that it needs to use 3x more area, but that 3x more gets consumed due to "advanced packaging and manfuacturing complexity". Which doesn't properly explain why it consumes 3x more and could simply mean they have a bad yield and 2/3 produced is garbage.
Classic DRAM stacks up to four wafers on top of each other and then is packaged with BGAs. The manufacturer can check the DRAM chips independently.
Soldering the DRAM onto a PCB is such a reliable process that there is almost zero risk of defects and even if a defect occurs the damage is limited. If the DRAM is soldered onto a DIMM the risk of a defect on the non memory hardware is non-existent. If the DRAM is soldered straight onto an SBC or GPU, then the DRAM can be removed to save the precious SoC or GPU chips.
Meanwhile HBM is the ultimate nightmare scenario. You stack up to 16 DRAM wafers on top of each other. One defect and the whole stack is worthless and that was actually the easy part.
In stage two things get even worse. You now have your accelerator chip and you must place the HBM on that chip. E.g. Blackwell GB300 has eight HBM stacks and the accelerator chip has a bigger area than the HBM. You must get the packaging right eight times in a row or you have wasted not only the DRAM silicon, but also the accelerator silicon because HBM cannot be removed and defects are permanent.
The issue here isn't just the yield of the HBM (which is obviously lower if you have taller stacks) but rather the yield of the combined HBM-based product, which is why doesn't make sense to say it needs more area but it is completely correct to say that HBM leads to more silicon being consumed. Hence it doesn't make sense to talk about yield of the HBM itself, because it is always part of an integrated product.
You make HBM by stacking a whole bunch of dies on top of each other. The signals from the upper dies need to pass through vias in the lower dies to get out - taking up valuable die space in a way which simply isn't needed with regular DDR. Similarly, HBM has a far wider bus, so each individual die has, say, 16 banks of depth 32, rather than 4 banks of depth 128. That's more control area needed per byte of memory.
Those two combined already result in a huge reduction in bytes per mm2, so with the same wafer processing capacity you're producing far less byte of memory. Add to that a complicated chain of HBM-specific packaging steps, and you're now also losing a decent bunch of perfectly-fine dies because rather than putting it into DDR you tried making a HBM sandwich and screwed up.
Even if the memory cells are the same and have an absolutely identical yield, HBM will always end up having a significantly lower output. That's just the cost of stacking, but some people are willing to pay the per-gigabyte price penalty in return for the higher bandwidth.
This might not be far off the mark. You are irreversibly linking the fates of these devices after a certain stage of manufacturing. If something goes wrong at final packaging time, you lose all dies instead of one.
From what I understand the whole point is avoiding the need to stomp pedals or otherwise touch them during live performance.
Some pedals have a bunch of knobs which are a pain to adjust during live performance between the songs. So some pedals support changing the settings using MIDI interface. This device has builtin library of control codes fur such pedals. That way you can program presets for your MIDI controlled pedals in the storm summoner and during live performance quickly switch between presets with a click of single button as opposed to remember which of the half dozen pedals need to be stomped on/off for each song or worse adjusting the knobs.
Oh, ok thanks for the explanation, I can see the utility of it there. I thought it was more like "hey here's a stompbox but you can't stomp it and we switched those pesky knobs with a touch-senstive surface like cars did and everyone hates".
All without a DAW too I'm guessing? I use an FCB-1010 for a lot of things but yeah it's obviously pretty useless without a DAW.
People bring this up to every RISC-V discussion but the same could be said for ARM or x86. For which ARM instruction set is built? Does this ARM cpu support integer division instructions, does support arm and thumb instruction encoding, only arm, only thumb, does it have a floating point unit, does it have neon, does it have MMU. Those are still relevant questions for ARM cores.
On x86 situation is even crazier https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html . Some of the more recent CPUs list ~60 optional features. Even if you look just at generic common profiles you have i386, i486, i586, i686, x86-64, x86-64-v2, x86-64-v3, x86-64-v4. Just a single family of vector instructions has 6 different versions for example: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2. I am not even going to try counting all the variations and optional instructions of AVX512.
On one hand this is an important topic, especially in contexts like which X86-64 profile are the software in Linux distro official repositories targeting.
At the same time no one is bothered by 20 cent ARM mcu not having instructions for atomic memory access, supervisor, SIMD or even floating point.
So if anything RISC-V instruction set optional feature sets are probably better structured and less fragmented (for now) than the current situation with ARM and x86.
If you'd limit yourself to cores implementing the Application profile of ARM (Armv8-A etc), you'd do the same and limit yourself to cores implementing the Application profile of RISC-V (RVA23 etc). In that case, you can assume vector instructions and everything else.
If you don't, you get the exact same kind of question with ARM as with RISC-V. Do you use NEON or with SVE? Or do you conservatively compile without vector instructions at all even though it could possibly result in speed-ups for some loops?
I don't think you're giving ARM credit for the ever growing pile of features which are always optional or optional only on some versions of the ISA.
For example, can you use FEAT_CSSC to improve code size and performance? Well, if the target is Targeting armv8a is the moral equivalent of targeting RV64GC insofar as it will run on any application class core. Targeting that, however, leaves a fair bit of useful ISA enhancements on the table, and so you tend not to want to do that if you can get away with it.
Micropython runs on tons of stuff and while it isnt capital-P Python, its close enough for doing a wide variety of embedded work without learning a new language/libraries/etc.
Matching decompilation is a verifiable target that ensures feature parity but it says nothing about being reasonable non slop decompilation.
Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.
Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.
I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.
The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.
Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.
Taking it to the extreme would be something like:
```
char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.
int main(){
((void*())data)(); // cast the array to function pointer and execute it
}
```
It might behave exactly like original program, but that's junk decompilation.
You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.
Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.
And almost any practical routing system will have a mechanism for tradeoffs of different aspects. Often there is a distance/time tradeoff which directly relates to speed on corresponding segments. But the tradeoff can also be in the form of "on average x seconds spent waiting green light in each intersection or time to stop before railroad crossing. So there is no reason for a system optimizing grade to completely ignore all other factors, it's just a question of weights and curves of each of them.
reply