Karliss
I guess in most industrial use cases it makes more sense to have a robot stationary and move the parts around with conveyors. Doing it that way allows to pipeline and parallelize the manufacturing process. In contrast the large operating volume covered by cable robot needs to be served by single robot exclusively.
Another interesting pattern I saw while browsing around was increased level next to every fancy cast iron light fixture along a specific bridge. The bridge was made mid 20th century so I don't think they are old enough to have used thorium gas light mantles.
Once you open corresponding panel in Rumble it shows you all the information you need to copy paste in single place with convenient copy to clipboard buttons.
Platforms with "builtin support" require same amount of configuration minus the server url. But since the server url is provided in the same place as stream key, copy pasting 2 instead of 1 value hardly makes a difference. It probably takes less time to copy server url than trying to find it in dropdown containing 70+ other services.
Google stadia had special builds, very well could have been DRM-free.
Other streaming services like G-force now are closer to renting a virtual machine with some automation scripts on top. Where after connecting you use a slightly modified version of steam to install games (which publishers allowed to be streamed) almost like you would install them locally. Those definitely aren't DRM-free (except a portion of indie titles which are DRM free everywhere). While G-force now tries to limit access to underlying OS, surface is too large to trust the platform with DRM free builds especially if it allows installing multiple games and steam workshop mods. It's a bit more complicated as g-force now also has "ready to play" games which provide more stadia like experience with better integration.
So overall it means 2 cases: * special builds/game specific integration scripts from streaming platform -> requires extra work and agreement between streaming platform and developer/publisher, introduces uncertainty of how streaming platform limits account sharing (compared to the DRM publisher uses) * no extra work, just single checkbox in steam developer panel -> potential conflicts with finger printing, DRM and anticheat systems
Neither of 2 are no brainer free money. Either it's extra work and bureaucracy to negotiate, prepare and configure special build. Or it's conflicting with DRM systems.
It's trivial only for smaller indie devs who are uploading DRM free builds to steam anyway.
For DRM and ban avoidance detection this means either false positives (which is bad rep) or if it's tuned to ignore those signals on specific service provider hardware makes it easier to do account sharing (and thus not buying the game).
Which leaves user space drivers embedded in the app as more or less only option. I am a bit surprised Apple allows enough low level thunderbolt access to implement this at all. On a desktop you could implement a user space driver in a shared library so that it can be used by multiple apps, but that's not really an option on iOS either.
Such approach is hardly rare. Many niche hardware products do something similar. Either implement driver/interface for generic data transfer device (like a serial port), or use the slots for vendor specific data within HID, bluetooth interfaces and implement a custom protocol on top of that. Almost any bluetooth device which requires vendor app for configuration, many smartwatches, gamer keyboards/mice which require custom app for configuring RGB lights (often HID based), even MCU programmers and other serious electronics development tools often show up as USB serial ports.
Based on that I would expect that if you advertise in small town newspaper, the job needs to be located in that small town. Want them to work in your big office next to big city, then it must be a newspaper widely distributed in that city not a small town on the opposite side of continent.
The effects in some of the demos simply kill any video encoder, only way to properly experience them is by running or emulating locally. Not that crystal sharp upscaled square pixels on modern display or poor quality CRT filters are very representative either, but it's likely better than blurry mess you get when video encoder tries to deal with high frequency details or random noise from procedural effects.
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.
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.
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.
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.
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.
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.
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.
They seem to be happy with extra engagement from people who hate the name. https://blog.ploopy.co/yall-need-a-new-name-48