Compression is also certainly on the cards, but really comes in to its own once we have the clients running on resource-constrained devices.
623 karma · joined April 30, 2014
Compression is also certainly on the cards, but really comes in to its own once we have the clients running on resource-constrained devices.
Regarding data use - you're completely right. In previous production IoT projects we've worked on we've had in excess of 10X more debug data than actual useful information coming out, lest we're not able to debug problems! We've got a few tricks up our sleeve, the main one being that this only sends data when there is an exception.
[1]: https://ianskerrett.wordpress.com/2017/04/19/iot-developer-t... (Point 4)
That should probably be written as secure-MQTT, I'll get that changed. So we are just using vanilla MQTT over TLS.
We're currently using token-based authentication but certainly open to supporting other options. Did you have any suggestions?
I'm not quite sure what you mean about validation? In general, the gateway will already be in communication with the end devices over whatever protocol they're using. So it makes sense to log state etc. from the gateway for those devices. In that sense, the gateway does act as a gateway for overlock.
We've got loads of other things we want to do in this space too, but we feel that these two are what's missing from exception tracking at the moment. We believe that IoT needs better tooling to get more reliable and secure.
[0] https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_ru...
[1] https://play.rust-lang.org/?gist=cadcbee43557e8e3bbe0&versio...
I don't see how that is any different with a per-user pot than the current system?
Additionally, I think your first two points mostly address the outliers on the bell curve.
It seems to me that GP's solution would be at least somewhat more fair than the current system although its certainly not perfect.
So 60 000 AS would give around 9TB
There doesn't actually seem to be a way to explicitly free memory though so I doubt this is actually used.
Additionally, the rust / servo community is very good, so you can usually get help pretty quickly on IRC.
[1]: https://github.com/servo/servo/issues?q=is%3Aopen+is%3Aissue...
Having recently switched, PyCharm really does make larger projects a lot easier to refactor / manage.
Edit: Also, to actually answer your question, this is a relatively new feature so I don't think any of the VIM plugins support it yet. Jedi has had type hinting from doc strings for some time now. I'd imagine they'll update that to use this soon.
The article suggests that government organisations (presumably 'secret services') are some of their biggest clients.
The problem I think is that ICRs don't fall under the rules for interception. They seem to be a part of communications data:
A kind of communications data, an ICR is a record of the internet services a specific device has connected to, such as a website or instant messaging application.
Communications data doesn't have the same warrant requirements.
Police have to request the ICRs for an individual on a case-by-case basis, going through a 'senior officer' who takes advice from a single point of contact (SPoC), although I can't find any criteria for SPoC selection.
In any case, there's no judicial oversight on ICR requests as far as I can see.
So no warrant would be needed to get a list of domains a person has visited.
We can promise you that no two projects will be the same and that you’ll get to work with a wide variety of amazing companies.
We maintain a technology blog here: https://zoetrope.io/tech-blog. We’d love to know what you think. We’re looking for a multi-talented software engineer to join our Bristol team. An ideal candidate will be at home with developing API’s, backends and occasionally even some front end work.
Given the size of the team (currently 3.5), it’s essential that we find an all rounder who will be happy to muck in and help complete the project.
Interested? Send over a cover letter, CV and ideally github / code sample to jobs@zoetrope.io
https://github.com/redox-os/redox
It's pretty incredible how quickly it's come together, there's a reasonable looking GUI already!
Edit: The author also did an AMA on reddit: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51...
An occasional hanging frame, but nothing serious.
Zoetrope is a young and fast growing technology consultancy focusing on IoT, based in Bristol. We pride ourselves on being the whole package - from transistor, to 3D print, to server, to web interface. We work on projects both with multinationals and startups as the virtual technology team, helping to drive the specification, prototyping and implementation of the client’s product.
We can promise you that no two projects will be the same and that you’ll get to work with a wide variety of amazing companies.
We maintain a technology blog here: https://zoetrope.io/tech-blog. We’d love to know what you think.
We’re looking for a multi-talented software engineer to join our Bristol team. An ideal candidate will be at home with developing API’s, backends and occasionally even some front end work.
Given the size of the team (currently 3.5), it’s essential that we find an all rounder who will be happy to muck in and help complete the project.
Interested? Send over a cover letter, CV and ideally github / code sample to jobs@zoetrope.io
To my mind, their system far outstrips the other couriers.
They would have to split the fleet, all business deliveries still need to be made 9-5.
Amazon have actually started doing this in reverse in the UK, you can set an address as a business address and your package should only be delivered 9-5. In practice the 'Amazon Logistics' drivers (the aforementioned blokes in cars) are terrible and rarely manage to get this right.
The beta API someone threw up on github obviously isn't going to help the average consumer, but it might be the start of a community of enthusiasts. Maybe one day those enthusiasts build a robust system with wider adoption and a company behind it.
If you want something that 'just works', then github is probably not the first place you should look.
In Europe, if a motorist wants to drive a small car that feels like a big one, there is a diesel for every occasion.
A 1.6-litre turbodiesel delivers the torque surge of a much larger gasoline engine, yet with the fuel efficiency of a much smaller one. In the UK, diesel sales account for more than half of all cars sold, and even with a stat like that, Britain lags the rest of Europe, which has long preferred diesel to gas.
So why would more Americans not drive diesels? From the European perspective, it would suit the driving style of the States perfectly, with lots of relaxed muscle available at low rpms to cruise vast interstate networks that are the envy of the world. Better mileage means fewer fill-ups, and the on-paper improvements in fuel economy would, overnight, take the US fleet one massive step toward President Obama’s targeted 54.5 mpg national average by 2025. Simply stated, diesel should “work” in the US.
“But what do Britons know about our market?” an American might opine. Quite a lot. In significant ways, the diesel market in the US is similar to that of the UK three decades ago.
In the UK of the 1980s, diesel drivers were outcasts. They were required to fill up around the back of the station, over by the truckers, to be looked upon by gasoline burners with a mixture of pity and smugness. And that presumed diesel drivers could even find somewhere to fill up, as not every filling station bothered to stock their fuel.
This sheer lack of availability led to great variability in pricing. As the only filling-station proprietor in 25 miles to stock diesel, Mr. Smith could subsequently charge more or less whatever he wanted. A survey of diesel prices in the US illustrates a similarly maddening snapshot of how scarcity can produce wide price fluctuations, with pump prices varying by up to 50 cents a gallon. But with more diesel purchasers, the laws of the marketplace would kick in, bringing prices into greater alignment.
Given the need for low-sulphur refining, diesel would not necessarily become cheaper than premium in the US. It is pricier on the other side of the Pond, too, but although Europeans gripe about it, they still know the savings add up. Diesel generally returns 30% better mileage than gas, and in the dominion of $8 gallons, this is no small advantage.
Mind you, there are two distinct factors working in favour of Europeans’ wallets: fuel with a higher cetane rating, which makes it easier to control NOx emissions, and EU emissions standards that are generally comparable to the US’s Tier 2 standards in all areas apart from, yes, NOx. Even our EU 6 standards, due in 2015, do not quite match the States’ strict limits on smog- and acid rain-causing emissions.
Relative to a gasoline-burning engine, it is more difficult to control NOx in a diesel, which is why, to meet those comparatively stricter emissions limits, diesels in the US are required to use expensive, onboard after-treatment systems, which decrease the amount of particulate matter that leaves the tailpipe. Diesel engines are already more expensive to develop than gasoline units, given their turbos and complex injection systems. After-treatment systems make them even pricier.
Here’s the thing: It’s worth it. Diesel used to be a dirty fuel and a dirty word, but recent technologies have addressed both problems, which is why the world outside the United States thinks of the choice between gasoline and diesel as a foregone conclusion. And even with the additional costs, passed on to the consumer, of emissions compliance equipment, the sensory pleasures of a diesel-powered vehicle are difficult to deny.
It is high time, America, to give diesels a better look.