dognotdog
I almost never change the defocus control on the 135/2.0 from neutral, yet I believe the lens makes it almost impossible to take a bad portrait. The only reason to keep a DSLR around instead of a mirrorless is that this lens has an old-school camera driven auto-focus, which Nikon's F-to-Z adapters don't support. While manually focusing that lens can be done, the shallow depth of field makes it very challenging for moving subjects.
I’ve migrated a lot of projects from fossil to git eventually, but I dare say they never would have made it that far, had I started out with more friction, including fighting vcs tools.
Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of not getting it to work, I just thought screw it, I'll drop everything into fossil, and that was it. I have my issue tracker and wiki and everything, though admittedly I'll have some friction later on if I want to share this project. Not having to deal with random git-lfs errors later on when trying to merge commits with these large files is a plus, and if I ever want to, I can fast-export the repo and ingest it into git.
Octopart, etc haven't been able to accurately track inventory through this disruption.
Its simplicity also made it great to write an interpreter for, including GC. However, nowadays the focus shifted to JIT, mostly via LLVM, which leaves such free-form languages unable to compete on performance, without significant effort.
I do fondly remember the endless explorative chats with Steve Dekorte and the other language geeks on IRC!
I don't think the same is true for software "engineering," as it seems that all possible forms of process can be subverted and cargo-culted, from agile methods down to code checking. Certainly there is room to remedy some shortcomings, but SWE definitely is the engineering discipline least based in physical fact.
The physics behind simulating the buckling of a structure is always the same, we can just choose more or less crude approximations of it, but SWE in general seems a lot more diverse. I can implement that simulation in assembly or some scripting language, and attach various bits and pieces to it to manage users and data; deploy it across the cloud if need be. But, there isn't a singular, time-invariant optimal path to achieving that, and what is true today may not be true tomorrow. One can work off basic principles, like the Agile Manifesto, but how can you quantify or even certify this shifting landscape?
David Rosen pulled off quite a few little masterpieces -- his gamedev competition entries always had fantastically unique aspects. I cannot believe "Black Shades" was almost 20 years ago! (I have no affiliation, but I am glad to see https://www.wolfire.com/games is still alive and kicking!)
Lugaru and later Overgrowth have been the outcomes of what can only be called a decades long obsession with getting the player controls just right, allowing very natural and responsive control and movement, through creating emergent behaviors from first principles, resulting in a rich and natural interaction with the environment (and other characters, see the fighting mojo), in contrast to the many, many AAA titles that just constantly break the immersion through unnatural, jarring behaviors and frustrating limitations.
With inexpensive optical scattering sensors, the situation is even worse. While it is easy enough enough to "count" individual 2.5um particles, the scattering equations work out to an order of 10^6 reduction in scattering amplitude, per particle, going down to 0.3um (when measured with red or infra-red light), and different particle compositions will scatter differently. On top of that, the number of particles increases significantly per unit mass concentration, making the signal processing a lot harder once one can't just threshold individual "blips" in the signal.
Whether the sensors are particle counting or nephelometric in principle, the basic trade-off is that to see smaller particles, they need higher amplification factors, which in turn increases thermal noise, also amplifies stray light, and makes the device more sensitive to EM interference. Many signal processing pipelines do simplistic noise filtering, throwing out much of the baby with the bathwater.
On top of these principal difficulties, the optical scattering type sensors are quite sensitive to temperature variation, and aging of the photoelectronic components, which is why field tests under varied conditions often depress their accuracy even further.
Long story short, it is very easy to build a sensor with qualitatively good correlations to actual PM concentration, as long as the PM concentration is sufficiently high, but the health effects have no threshold, and every added bit of pollution counts, starting at zero. Unfortunately, commodity PM sensors are quite bad at quantifying these low, yet meaningful, ambient pollutant levels, which is probably why IKEA chose their traffic light thresholds the way the did: not because of how it relates to health, but because this is what they could do with a $12 device.
However, space craft would be where being able to run hotter would significantly reduce the size and complexity of cooling systems, as they can only use radiative cooling bleed off the heat they generate into space.
Using parallax to calculate depth undoubtedly has principal limitations in far away details, and mapping to an 8-bit depth buffer is another very reductive step in that regard. (regardless, I'd expect even the folds to show up, at least qualitatively, if I'd looked at an 8-bit rendering of a 3D scene's z-buffer; the gradient contour steps are clearly visible, and dense, yet fail to follow the folds, indicating that the underlying depth data simply doesn't track them at all)
Let's take the sleeves then -- clearly a large difference in relative depth, yet they blend into the rest of the garment. My impression is very much that of standard depth reconstruction "AI" that more or less guesses depths of a few image features, and does some DNN magic around where to blend smoothly and where to allow discontinuities, with the usual "weirdness" around features that don't quite fit the training sets.
Possibly all we can get out of this "parallax" method of depth reconstruction isn't a whole lot better than just single image deep learning, which would not surprise me, as it ultimately relies on the same approach for correctly recognizing and mapping image features across the 9 constituent images in the first place, vs. a true lightfield sensor that captures the actual direction of incoming light.
[1] https://www.omnigroup.com/omniplan/features/#Monte-Carlo-Sim...
> Another red herring here... it is irrelevant how superficially close this is to the original source code.
It wasn't until Apple vs. Franklin that object code became copyrightable, prior to that the USPTO held the analogy of "design drawings vs. actual bridge" as the relation of "source vs. object code", and as far as I am aware that case still left some questions open.
There's also the first sale doctrine. So, once I buy a (mechanical, haha) car, I can modify it, take measurements of it, in fact describe and publish every bit of information I can think up of, right, because once it was given to me, I can do with it as I please, unimpeded by the manufacturer. This is, of course, where things get murky.
Now, a binary has elements of literal nature that copyright protects, but a decompilation results in a completely different information stream, so that seems like a non issue. Thus, we are left with the non-literal copyrightable elements of structure, sequence, organization. Copyright protects expression, but not ideas. So, the binary code is an expression of the author's ideas, and thus it seems sensible that the decompiled version is, too, BUT: only creative expression, not things that are necessary and utilitarian to perform a given function, and this is where it get's less well-defined. So if there are decompiled portions, that might not be enough for a copyright claim, provided they are utilitarian in nature. Of course, just decompiling the whole thing and publishing that looks very much like infringemen, indeed.
I do think this nicely embodies the difficulty of dealing with IP vs. actual, tangible things, though. With the car or bridge analogs, copyright would not prevent anyone from replicating them, but it would be patents and trademarks that put restrictions on how and what can be reproduced, instead of the much stronger restrictions of copyright on software.
I'd personally much more comfortably equate binary code with mechanical elements than works of creative authorship (though much of my livelyhood relies on the latter, in lieu of other mechanisms), but this view isn't universally shared, and possibly not even universally applicable.
Decompilation / reverse engineering is very different from "transcribing" a play. Transcribing a play, you would get back an almost exact copy of the source material, whereas decompiling is more akin to taking a car and measuring all the bits of it. You would certainly not get the original drawings or CAD files back out of it. You do not decompile "source code", but machine code, and the source code you get back is not a recreation of the original copyrighted code, but the decompiler's analysis of the machine instructions, stripped of the original design and intent (the creative work part which makes source code copyrightable in the first place).
Measurements (or information) in general is not copyrightable, despite what IP protectionism claims, and in this analogy the machine code is much closer to the mechanical pieces of the car that make it work than the original designs. Either way, the fair use / reverse engineering provisions already create an exemption.
The questions is wether there are enough legal loopholes to squash these generally allowed uses through some other parts of the law or licensing terms, eg. by claiming that some IP (patents, trade secrets) are infringed some other way by publishing the reverse engineered code.