dognotdog

I am a big fan of learning LISP, at least once. Going through SICP after more than a decade of writing code for a living was probably the single best thing I did to deepen my understanding of a lot of compsci concepts, data structures, and how to think about software. For me, at least, it was very much a seeing the matrix for the first time kind of moment. My LISP use has quickly declined, but I've dabbled in dozens of programming languages since then, and I do attribute not feeling lost to that experience.

Indeed, how exciting a phone would be that fit in... you know... bear with me... your pants' pocket you already have... lol

Indeed I have 3D assets in this case. Would this be done differently in an enterprise that has all kinds of tools to manage specialty workflows? Sure. Do I want to spend my days configuring and maintaining some binary blob / LFS storage system? No.

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.

I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab.

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.

I was under the impression you could only activate one esim at a time, but store up to 6(?) on that phone?

This is probably a longer discussion, but PM0.3 (anything less than 0.3 microns) is quite difficult to measure, especially optically, as light scattering drops off very steeply once your particle sizes are around the wavelength of the light being used. Anything short of an SMPS class instrument that “grows” small particles through condensation so that they appear large enough to be counted, will not see much below 0.3 microns. Also, the total MASS of small particles might be low, but if you look at count, or lung-deposited surface area, we get a different picture. Especially around 0.3um, particulate matter is prone to get deep into the lungs, instead of being caught in the upper airways, and the small size means larger relative surface area, and thus higher reactivity. Even smaller nano particles might not go as deep, but are more likely to enter cells or the bloodstream due to their minuscule size.

While I admire the efforts of the SC-AQMD, and generally agree with the article, using R2 from a higher-end, but not quite perfect instrument, can be quite misleading, and is not a great indicator of actual sensor performance. Also, there are a lot of potential improvements in sensor tech, but instead almost everyone is relying on the same cheap sensor modules instead of innovating, which have have pretty bad deficiencies, especially in detecting particulates in the ultra-fine range, and don’t age very well. But, they are the cheapest.

I kind of went the other way as github/gitlab took off. I was using fossil for years because it was so self contained with issue tracking and everything, and it is great, but the lack of easy two-way interop with github had me gradually drop it for new projects, when I anticipate some level of other contributors. That being said, going from fossil->git via git-export is very simple and painless.

My understanding is that Quicktime Player has been in the SIP domain for recent OS releases, so it just won't load 3rd party libraries at all :/

I've created PTP Webcam [1] during COVID to get DSLRs working for video conferencing on the Mac.

[1] https://ptpwebcam.org/

I'd claim things are more nuanced. There are many reasons why UIs in many places, not just cars, suck. In cars, wether warranted or not, there is also pressure from legal to err on the side of building a cludge that is unassailable vs. a smooth user experience that could be grounds for a class action because it doesn't make enough of an effort to discourage dangerous user behavior.

I just bought 10 off digikey last week, to have some prototyping stock. Looks like they still got some: https://www.digikey.com/en/products/detail/stmicroelectronic...

Octopart, etc haven't been able to accurately track inventory through this disruption.

Wouldn't an open lamp severely degrade all kinds of paints and materials that aren't meant to be exposed to UV light? Or does the mechanism that supposedly makes the shorter wavelength safe for human skin cells apply to all materials?

So far, so good -- let's see what the pricing will be like :)

I’ve just finished an rpi based device that would be going into mass production if it wasn’t for the parts shortage, with some digital IO and I2C. It took me about a year calendar time to convert the software stack to elixir+nerves as a side project, with many improvements just because of the good infrastructure support for remote deployment. Circuits wasn’t particularly weird, though it had only limited support for some advanced GPIO functions.

Seeing the same in PA, quarts of many brands are out of stock at various stores, but half gallon and up are available.

I think "dynamic and introspective" would have been more precise, as opposed to "free form" grammars.

Io was fantastic as a personal learning vehicle, over ten years ago. I did have a game project that used it, right in the lull where Lua’s FFI was still a little rough and JS did not quite break out of the browser.

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!

One can verify and sign off on computations that approximate the physics or chemistry that will occur in a structure or machine, as a well established chain of procedures exist to go from crude formulaic approximations to micro or, if necessary, nano-scale simulations of electrical, mechanical, and chemical processes, and we know what to look for.

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?

https://youtu.be/LNidsMesxSE?t=674

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.

IMO, the single biggest problem is that even five-figure reference instruments disagree considerably in the 0-20 ug/m3 range, and if you look at the figures of the SCAQMD tests, you won't see much more than noise in the scatter plots in that range, with increasing consistency at larger concentrations. Some of this is due to mismatches in response times and synchronization, but a lot of it is due to different disturbances, noise processes, and varying sensitivities to different particle size distributions in different sensor types.

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.

As radiative cooling is a temperature to the 4th power (T^4) process, vs. linear (T^1) for conductive and convective cooling, one could certainly increase power density for general electronics, though the danger of setting something on fire, and actually needing higher temperature packaging / soldering / bonding processes might put a crimp on that.

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.

I'm not so convinced I'm seeing the limits of resolution, either angular or depth.

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.

It is kind of disappointing that it doesn't seem to map any of the folds in the garment, the individual fingers, or other details. It also seems to get the depth around the knob by the right elbow quite wrong. All-in-all, no apparent order-of-magnitude (if any?) improvement over single image "AI" algorithms that have been shown before.

A nice exposition! I think Omniplan does this [1], and it certainly helped me in the past get a better idea on variability of long-term project planning. Of course, it's only as good as the assumptions that go into it!

[1] https://www.omnigroup.com/omniplan/features/#Monte-Carlo-Sim...

That PCBite probe setup look nifty indeed, thanks for the tip (pun intended)!

Interesting points! I am not sure which is right, or legal, but there seem to be grey zones, yet.

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.

It seems like using something that's reverse engineering to achieve "interoperability", in this case playing the games on modern hardware, is generally legal in the US/EU, as long as you also own a license to the original, which seems like is a requirement to use the Re* versions, as you need the original game assets.

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.

Yes, higher exhaust temperature is not a direct indicator. For the same airflow, higher exhaust temperature suggests more energy being carried away, which can reduce chip temp, all else being the same. If the airflow was reduced, but the heat pipe improved, it could still be that chip temp stayed the same.

Why do you think it's impossible? To me, it seems like all effects (eg. mechanical waves) would propagate at much slower speeds than the speed of light. This kind of control system experiencing significant delays and dead-times is not uncommon.