[1] https://docs.particle.io/reference/device-os/firmware/#movet...
461 karma · joined September 27, 2016
[1] https://docs.particle.io/reference/device-os/firmware/#movet...
On the Photon at least, emulating a keyboard and mouse is incredibly easy and is baked into the firmware, but implementing the Barrier protocol so that it can appear as a client on the network and pass on the keyboard/mouse input seems like it's going to take some effort.
[1] https://docs.particle.io/photon/ [2] https://beagleboard.org/black
It's interesting to consider the implications of this line of thinking though; it seems like it would imply that causally-disconnected regions of spacetime (i.e. things outside of our light cone) are forever in a superposition of all possible quantum states, from our perspective, among other things.
Of course, this is probably only remotely feasible in languages that can guarantee that toString() won't have any side effects.
PowerShell's [SecureString] type is something of a step in the right direction, although its execution is lacking in some respects.
In any case, stack traces should _always_ be treated as secrets.
Even better would be including the current values of any local variables introduced within the function, and any global variables referenced within the function.
As an example of how this might work, suppose you want a data structure that provides an ordered collection of items, with the ability to insert, randomly access, remove, and iterate over them. The compiler/library/runtime might be able to supply any of a binary tree, a linked list, or an array. You, the programmer, have some idea of the distribution of the data that will be stored in the collection (e.g. the collection will contain integers between a specific range) and the operations your program will perform on it (e.g. the collection will never be iterated over, insertions will be twice as common as removals, only the first/last elements will ever be accessed at any given time). The compiler knows the performance characteristics of each of the operations over various distributions of data (e.g. linked list insertion has a cost of O(1), random access has a cost of O(n), removal has a cost of O(1)). The language would allow the programmer to provide the compiler with hints about the expected distributions of data and operations, and the compiler would use this to pick the optimal data structure for the use case. Another example might be the compiler picking a sorting algorithm automatically, based on the expected distribution of collection sizes and data (e.g. automatically pick insertion sort of the collections are typically small and already partially sorted, but pick merge sort if they are typically large and unsorted).
It would also be interesting if this language/runtime could enable sampling of statistics on the actual observed distributions of data/operations under production workloads, and make it easy to update the programmer's specified distributions to get better performance with minimal effort. Or if the compiler could be given the performance characteristics of the target hardware as well, which could impact its choices. Maybe the program will be reading from an SSD, making the overhead of caching something in memory no longer worth it?
More broadly, it would be very cool if program semantics and performance could be decoupled entirely, and the compiler could have the ultimate freedom to pick the optimal data structures and algorithms so long as the program's observed behavior remained the same.
It's orbiting at the Earth-Sun L2 Lagrange point, with a perigee of 374,000 km
While we can put astronauts in space, we don't currently have any orbital vehicles with on-orbit satellite maintenance capabilities, since none of them have airlocks
The latter could very well change over the next few decades though, and the former may become economical, so I guess it can't be entirely ruled out.
On the other hand, LCD could be used to create an opacity-changing window, but LCD panels block a lot of light even when they're fully "transparent," which is why they consume so much power (their backlights have to be very bright).
Personally, I would be in favor of UBI, even as someone who would see a net loss on it after taxes, since it would mean that if I ever lose my job (or choose to quit), I will still have the UBI to support myself with while I look for a new one, making it a less stressful event.
[0] https://en.wikipedia.org/wiki/Land_value_tax [1] https://en.wikipedia.org/wiki/Georgism
To be sure, PKI and certificates in particular have a lot of room for improvement in the UX department. Especially on Windows, where one frequently has to deal with not just .pem files but .cer, .pfx (with or without private keys), and more.
* man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge)
* requesting a new certificate for that domain
* spoofing the HTTP resource response (or DNS response, if applicable)
I suppose this is mitigated by the way Let's Encrypt validates the agent software's public key on first use though, at least for websites that are currently using Let's Encrypt.On the other hand, this would probably cause app ratings to tend much more strongly towards the median, which could make them less effective signals of quality.