Working from the fact that the NetBSD sees the OHCI controllers which are on the Starlet's AHB this runs with AHBPROT disabled (as does most homebrew), so NetBSD can in theory not only interact with Starlet mailboxes (as any normal game), but can also do pretty much anything to it as the entire Starlet address space is R/W accessible from Broadway (which on the other hand makes interacting with Starlet pretty much irelevant for normal use, as you can interact with the hardware directly using normal drivers instead of going through IOS)
Doing similar idea with asymetric cryptography is problematic due to the size of messages involved that are not exactly convenient to type. Lower bound for the signature size is going to be something on the order of 128bits if we include "weird" signature algorithms (ie. string that looks like MS Product Key), 240b for Schnorr with safe-ish parameters, at least 512b for anything widely accepted.
You can probably come up with something related to S/KEY (which was kind of a precursor to HOTP) that can be made to work with arbitrary sized one time passwords and is technically asymetric (and quantum resistant at that), but the security trade-offs involved in that and somewhat wild user registration step of S/KEY make HOTP/TOTP more sane choice.
And many actual implementations work the other way around. Which opens the user to credential compromise but is much better user experience (and only one possible with several kinds of hardware tokens).
In my opinion that was step in the right direction, but the protocol design is truly weird. Somehow managing to come up with 4 different ways to encode length of byte strings in otherwise so simple protocol is remarkable achievement.
Interesting contrast to this is that most modern vector 2D graphics API use PostScript/PDF drawing model that cannot represent exact circles and elipses and these are instead interpolated by a bunch of bezier curve segments.
Bezier curves (the regular kind) cannot represent circles and ellipses, this is true. However, rational Bezier curves can [1]. I don't know if PostScript has a rational Bezier primitive, but some drawing libraries do. A prominent example of a library that does is Skia, the rendering engine behind Chrome and Android.
I don't think that's true. Drawing Bezier curves is not any easier than drawing ellipses, and in fact I'm pretty sure it's even more difficult. If someone wants to approximate an ellipse the easiest solution is to just draw a bunch of short segments.
Can you provide examples? I have not seen an API not to support circles and arcs. SVG is AFAIK the most common API, you have there circles, arcs, ellipsis, quadratic and cubic beziers etc.
This is how SVG and most other drawing programs are implemented under the hood.
Down at the lowest level the engine can only really do straight lines. You may ask for a circle or a bezier, but the engine only approximates this with enough fidelity that you wouldn't notice the flaws. Beziers end up being approximated as a bunch of tiny line segments. Circles and ellipses can be approximated pretty easily as a handful of beziers.
Beziers are particularly useful because they have some handy properties. You don't need to do any trig to calculate them (like you do for arcs). They're extremely simple to compute, and any bezier curve can be split into two smaller bezier curves. That last fact makes it easier to have varying fidelity along the curve.
Source: was on the original SVG Working Group team @ Adobe.
def bezier(t, *handles):
"""Computes a single point of a bezier of any order where 0 <= t <= 1."""
if len(handles) == 1:
return handles[0]
else:
pairs = zip(handles[:-1], handles[1:])
return bezier(t, *[_bezier_interpolate(t, a, b) for a, b in pairs])
def _bezier_interpolate(t, a, b):
return [a * (1-t) + b * t for a, b in zip(a, b)]
assert bezier(0.25, [1, 1, 1], [2, 2, 2], [3, 4, 5]) == [1.5, 1.5625, 1.625]
You can pass it any order of bezier (cubic, quadratic, etc.) for any number of dimensions, and how for along the interpolation you are. It will give you a single point. Connect a bunch together to get your curve. You can actually stop when `len(handles) == 2` and you get line segments instead of points, but it's slightly less accurate.
You can see the math for computing a point (or segment) is trivial (addition and multiplication) and it can be easily parallelized. It can even be a one-liner, but that isn't very readable.
At least the PostScript variant used in PDF 1.7 only supports straight lines and cubic Bézier curves as path segments [0]. You may be able to hack together true circular disks using round line caps and joins.
If you want the resulting geometry to be precise you are pretty much limited to equivalent of compass and straightedge (or well, in mechanical engineering lathe and mill, which are basically the same things). if you start somehow calculating the geometry you are limited by precision of the calculation, but more importantly by precision of measuring distances you can achieve.
Another issue with modern recreations of old UIs is that the dimensions are usually subtly wrong, which for me ruins the feeling. Some of that is related to the fonts having different height, but in many cases it is just that something is one-pixel off and just looks wrong. For the 95-style UI the common issue are control borders (especially the high-light side of "3d" controls), of which there is a huge amount of examples on the screenshot.
There is a difference between DP+ and DP++. DP+ uses external level shifter, DP++ uses passive adapter and the card switches different transmitter into the path internally.
