But no, that’s actually the hard part. Something Apple did manage to accomplish quite well though (just like many other smaller companies would be able to do if there were no trivial patents preventing them from doing that).
Nokia is not the phone company but the network service’s provider.
Patent trolls do not produce products, Airbus and Nokia DO -very competitive- products. Airbus in particular is far superior to their competitor Boeing, which seems to be a sore point on many US-based commenters.
Nokia is no longer “the phone company”, Nokia refers to Nokia Networks (Alcatel included). Nokia, Huawei and Ericsson produce most of the wireless telco infrastructure today, which the US infrastructure depends on as no US company does this competetively.
The article itself is a bit on the FUD side of things tbh and the comments here are a bit uninformed.
He had ulcerative colitis. People more or less use "having an ulcer" as slang for being in a bad mood. Maybe he was like the giant with a thorn in its foot - something bothered him, and that made him less than in a good mood.
Really? Have been an xbmc/spmc user for years now got a new device with recent Kodi and default skin (I think) and it might be 'somewhat' clunky but I definitely wouldn't call it 'extremely clunky and slow'. I consider it just fine and not that much of a difference with spmc of a couple of years old. What are you runing it on?
I wouldn't call it clunky and slow, it is just meant to be used from a tv. It's like saying steam big picture mode is clunky if you use it with mouse and keyboard. Kodi has a good api, although there are no good web interfaces yet, I have been also contemplating trying to build a cli around it
It depends what hardware you are running Kodi on. I was running OpenElec on a raspberry pi, it was pretty much unusable for me. When I opened Kodi, the scan for new media would take ages, and often not work at all. Now I had a dedicated Windows 10 HTPC with an SSD, and the experience is night and day versus the rpi.
Yeah, I usually give up and go to Netflix or Plex.
Having to click in to each link, then in again to the stream, then load it up, then back out, and that process again for the next episode. Just one example but there are lots of things like that.
The Finnish news sources I follow paint this as a pilot initiative trialed primarily in Helsinki, and even then limited to a few courses. A country-wide scrapping of subjects seems still a long way off. The following passage from The Independent article seems the closest to the truth:
"Finnish schools are obliged to introduce a period of “phenomenon-based teaching” at least once a year. These projects can last several weeks. In Helsinki, they are pushing the reforms at a faster pace with schools encouraged to set aside two periods during the year for adopting the new approach. Ms Kyllonen’s blueprint, to be published later this month, envisages the reforms will be in place across all Finnish schools by 2020."
Did some more research and it seems that the subjects are not gone but there will be more project based learning that combines multiple subjects. The changes are already implemented.
Which source is this? There was a big change starting from this semester. It might not be as dramatic as the article says but it's still considered to be a huge change.
The gist I get is that it's a daemon for a gateway device (like a Raspberry Pi) that you configure data flows via JSON files. The Flogo CLI seems to be a JSON generator (https://github.com/TIBCOSoftware/flogo-cli/blob/master/READM...). They compare their functionality to Nodered (http://nodered.org/) except it doesn't have a GUI (they mention working on it) and instead of being written in Node.js, it's written in Go.
I'm of the opinion that these frameworks for Gateway devices are reinventing Unix pipe and cron, that integrations for devices and databases should be written in any language (as CLI), and running logic on the gateway is 90% of the time not what you want to do, you just want to pull data from a device and push it to a database somewhere. Shameless plug, in my free time I work on Open Pipe Kit, a project that is building CLI for devices and databases. We're currently working on a series of DIY LORA Nodes for Agriculture. If anyone is interested in lending a hand, please reach out. http://openpipekit.github.io
Nice work with the open pipe project. Looks perfect for DIY sensor/telemetry projects.
If you are looking to monetize connectivity services, you certainly will need a bi-directional architecture to push values back to end nodes, and compute resources available at the gateway for data filtering, preprocessing, and security.
But these are tasks that AWS IoT, Azure IoT, and GCP IoT are currently tackling with a lot of resources. So it would be hard to compete at that level.
Thanks. While our examples are usually "pull from some device and push to a database", with farmOS we experimented with "pull from a database and push to a device". In this way, pipes are used to transfer state of a device two ways. This depends on a database UI giving users the option to modify the state of something, something that IoT databases like Phant (http://data.sparkfun.com) and Adafruit IO (http://io.adafruit.com) don't currently support.
libwebsockets is better suited comparing to the pub/sub model for that? two-way communication is pretty tricky(NAT-traversal etc) sometimes, I am still opt for the old but reliable polling mode for most of IoT nodes.
Except the daemon part, I think you got the gist of it right - thank you!
The one thing I would like to add is that flogo-lib is a full-fledged process engine which means you can craft (or soon enough visually model!) rather expressive flow definitions unlike a request-reply pipeline or HTTP middleware.
(Disclaimer: I'm a PM working on Project Flogo at TIBCO)
Agreed. It also doesn't solve the biggest it challenge which is giving each thing a unique identity and a means to prove its identity. I find that real-time event processing had been solved already through dataflow and Apache Beam. Along with generic pub sub systems.
No, the biggest challenge in IoT right now is security and in that same vein, updates.
IoT devices identifying themselves (authentication) is only a tiny sliver of the security picture. You also need to worry about authorization, encryption, and (security) monitoring.
One really annoying security problem with IoT devices right now is SSL/TLS's complete fundamental incompatibility with the concept of "roaming". Want to connect to your device via SSL/TLS? Better get used to ignoring warnings about the certificate name not matching the device's IP/hostname.
Identity and encryption are tied hand in hand. It's about knowing where all the iot data is coming from, and knowing it wasn't spoofed.
It's kind of like HTTPS. nobody can snoop on you, but it's more about stopping malicious actors from lifting your identity. And making sure you are connected to the true requested server.
Fair point, we just chose a common Java REST or microservices fraemwork. Is there any particular Java IoT Integration framework you would like to compare or contrast Flogo with? Some OSGI framework like Kura perhaps?
Flogo's problem domain is broadly speaking, IoT integration. Using Flogo you can build integration apps/services/microservices that are lightweight enough to run dozens of these edge apps on IoT edge gateways & devices. Specifically, these edge integration services can be built as flows & triggers (yes, a visual flow modeler is coming soon!). Hope that clarifies - but we'll take your feedback to improve the docs.
(Disclaimer: I'm a TIBCO PM working on Project Flogo)
Sure sure.