Yes, its interesting to compare the de-facto standards around input and output parsing of CLI tools in Unix land. Input has been a solved problem since the 70s for simple use cases, it's output that was always a pain.
Inputs are arbitrary string STDIN and tokenized command line args (argv/argv). Outputs are arbitrary string STDOUT/STDERR and well-formed simple uint8_t return codes.
For input, most tools use the command line args for specifying tunable parameters. These are easy to adjust on the shell or in shell scripts, as opposed to deserializing & modifying & reserializing input files or STDIN. Most use the getopt convention (`myprog --input myfile -b 123`), which makes them well-formed enough to be a stable API and describable by simple grammars. As they are (usually) position independent key-value pairs (with some value arrays for multiple files etc), it makes it easy to add options without breaking existing callers. Look at the mountain of shell scripts out there that continue to run even as tools are updated.
For output, nothing similar exists. It would be interesting if UNIX tools could also output argc/argv and shells had builtin functions to easily parse (getopt style) and index into those. Or even just have a flat key-value envvar style return list. (I guess you could have a convention of the last line of STDOUT being dedicated to that and piping it into some tool that sets a bunch of prefixed env vars). Would have made everyday output parsing from random tools a whole lot easier instead of grep/sed/awk and the dealing with changing output as people updated the tools ("ifconfig" versus "ip" well-formed grammar).
Arrays and nested data structures are where everything gets complicated, and you need something like Powershell (powerful but clunky IMHO) or JSON and full programming languages. jshn is cool but verbose as its necessarily just a POSIX shell "extension".
Biological neurons don't just emit constant 0...1 float values, they communicate using time sensitive bursts of voltage known as "spike trains". Spiking Neural Networks (SNN) are a closer aproximation of natural networks than typical ML ANNs. [0] gives a quick overview.
Spike-Timing-Dependant-Plasticity is a local learning rule experimentally observed in biological neurons. It's a form of Hebbian learning, aka "Neurons that fire together wire together."
Summary from [1]. The top graph gives a clear picture of how the rule works.
> With STDP, repeated presynaptic spike arrival a few milliseconds before postsynaptic action potentials leads in many synapse types to Long-Term Potentiation (LTP) of the synapses, whereas repeated spike arrival after postsynaptic spikes leads to Long-Term Depression (LTD) of the same synapse.
We already have x86-64 (guarded licenses), ARM (less guarded but still uncertain) and SPARC, Power, RISC-V (open source).
Should a new ISA be the focus of major economic plans? Maybe if one of the objectives is protectionist ISA licensing, but that seems like an insular mistake.
An ISA ecosystem is a lingua-franca, so choosing a well established one is the most sensible basis for growing different semi/IT industry flows around.
In terms of discovering new technical benefits, new ISA's should be explored in academic circles and startups where they won't waste everyones time and money on boondoggles.
Fix proposal subthread. Can we harness HN collective intelligence to vote up some good suggestions?
Instructions:
* Reply with your suggested fix to this comment. (That way we can vote equally between suggestions, instead of having them being scattered throughout the thread).
* First line is simple one-line summary, optionally followed by a blank line then some exposition.
Example:
----------
Simple fix: Seperate links into 2 color coded sections, TEST and ACTIVE
Put each set of links into seperate divs, with different background colors or striped backgrounds.
Simple fix: Seperate links into 2 color coded sections, TEST and ACTIVE
Put each set of links into seperate divs, with different background colors or striped backgrounds. As is, these different links are mixed up together making them accident prone. Undoubtedly a mini development boondoggle will result over this incident, in the meantime the above fix is easy and satisifies the real requirement.
> A general solution to IoT security would be for all IoT devices to only communicate to your personally owned home gateway, which would run open-source drivers for each device to provide the networking/external communication functionality. The IoT device could even be assigned its own isolated network link to the router (i.e. sandboxed).
This is how my home works. My automation devices use Insteon, which is local only communication, and then my computer has an adapter for it that I wrote the software for.
This is a great solution to the ownership problem, but now each individual is responsible for patching and updating their 25 devices? Doesn't solve the security problem.
The home gateway could download the patches and send them to the devices. Its firewall will prevent them to phone home or somewhere else no matter what into those patches.
The movable-type printing press was invented 400 years earlier in China than Europe, but failed to take off due to the high number of characters (amoung other complexities).
> The world's first movable type printing press technology for printing paper books was [...] invented in ancient China around AD 1040 by [...] Bi Sheng
> Around 1450 Johannes Gutenberg made another version of a metal movable-type printing press in Europe
> The printing press may be regarded as one of the key factors fostering the Renaissance and due to its effectiveness, its use spread around the globe.
> The more limited number of characters needed for European languages was an important factor.
A general solution to IoT security would be for all IoT devices to only communicate to your personally owned home gateway, which would run open-source drivers for each device to provide the networking/external communication functionality. The IoT device could even be assigned its own isolated network link to the router (i.e. sandboxed).
That approach seems like the only logical conclusion for the device owners. I hope this is how the field will eventually evolve.
While its against the commercial interests of "Internet data" companies (who might subsidize devices), in the long term regular consumer appliance manufacturers will implement it if theres enough market pull for it.
That is kind of what Nest's Thread protocol allows IoT devices to do. But strangely enough, Google is going the opposite direction with its devices, including coming up with such stupid ideas of controlling your (OnHub) Wi-Fi router over the Internet through an app.
Thread is just an IPv6 wireless mesh routing protocol right [1][2]?. On its own it doesn't solve 2 key security problems:
* Any device can send arbitrary data to somewhere on the internet
* Internally, any devices can send arbitrary data to any other device
-----------------------
Another less-critical but important usability limitation is the short sighted nature of how device logic + APIs will evolve long-term for Device-to-Device communication.
Device-to-Device implies the application protocols are running on the devices themselves, which can't be bugfixed or upgraded by the user and in the majority of cases will likely never be updated by the manufacturer after release.
In [2] they give examples of devices like fridges and thermostats talking to each other. There's 3 long-term ways I see of handling device-to-device application APIs:
* Option 1: Raw device-to-device (Short term): How the hell will those APIs be agreed upon and evolve across multiple years and device products? Bluetooth now barely handles relatively simple interop use cases (files, contacts, audio...). Will Thermostat X support Fridge Protocol 8? How will the user handle more advanced use cases?
* Option 2: Vendor managed (Currently the most likely): The devices will talk to the vendor servers which will talk to other vendor servers which will talk to your other devices. Terrible for the user for so many reasons but great for the vendor: its the simplest to implement, keeps protocols secret and locks user into giving that specific vendor endpoint all that juicy data.
* Option 3: User managed (IMHO Preferable): Computer drivers are a much better model for this. Drivers sit over devices to transform the weird device API (fixed target) into a consistent interop API (community driven moving target) that does what people want. This still supports device-to-device: device A -> API call on gateway driver A -> gw driver interop API -> API call gateway driver B -> device B. This is what Option 2 (vendor managed) will actually have to do under the hood anyway. This could be implemented in a simple way e.g. with per-device(type) containers exposing a TCP/UDP port to the device.
I predict Option 3 to become mainstream when the year of the Linux desktop lands :D
God I am loving the justified hatred in this thread :D
I agree that in many respects the current corporate push for the Internet-Of-Things is mainly a wild-west style landgrab for self-serving integration into our daily lives.
However I don't think the IoT has to be this way.
I want all my IoT devices to only communicate to my home gateway, which would run open-source drivers for each device to provide the networking functionality. Problem solved. I don't know why this approach isn't getting more focus!
Inputs are arbitrary string STDIN and tokenized command line args (argv/argv). Outputs are arbitrary string STDOUT/STDERR and well-formed simple uint8_t return codes.
For input, most tools use the command line args for specifying tunable parameters. These are easy to adjust on the shell or in shell scripts, as opposed to deserializing & modifying & reserializing input files or STDIN. Most use the getopt convention (`myprog --input myfile -b 123`), which makes them well-formed enough to be a stable API and describable by simple grammars. As they are (usually) position independent key-value pairs (with some value arrays for multiple files etc), it makes it easy to add options without breaking existing callers. Look at the mountain of shell scripts out there that continue to run even as tools are updated.
For output, nothing similar exists. It would be interesting if UNIX tools could also output argc/argv and shells had builtin functions to easily parse (getopt style) and index into those. Or even just have a flat key-value envvar style return list. (I guess you could have a convention of the last line of STDOUT being dedicated to that and piping it into some tool that sets a bunch of prefixed env vars). Would have made everyday output parsing from random tools a whole lot easier instead of grep/sed/awk and the dealing with changing output as people updated the tools ("ifconfig" versus "ip" well-formed grammar).
Arrays and nested data structures are where everything gets complicated, and you need something like Powershell (powerful but clunky IMHO) or JSON and full programming languages. jshn is cool but verbose as its necessarily just a POSIX shell "extension".