[HN Gopher] Linux Foundation starts AgStack, an open-source agte...
___________________________________________________________________
Linux Foundation starts AgStack, an open-source agtech initiative
Author : teleforce
Score : 224 points
Date : 2021-05-08 12:52 UTC (10 hours ago)
(HTM) web link (investableuniverse.com)
(TXT) w3m dump (investableuniverse.com)
| pm90 wrote:
| I'm concerned about the Linux Foundation being involved in all
| these projects. I expected it to be an organization dedicated to
| Linux. But it seems to have expanded to a myriad of different
| spaces and it's endorsement is often used to legitimize really
| bad products, ideas and initiatives (look at the finops
| nonsense).
|
| Can't they just be stewards of Linux kernel development and focus
| on that? If there are other initiatives just create other
| foundations or redirect funding to those areas.
| ghaff wrote:
| >Can't they just be stewards of Linux kernel development and
| focus on that? If there are other initiatives just create other
| foundations
|
| The way a lot of these other initiatives are organized is they
| _are_ their own foundations /projects under the LF umbrella
| which lets them share infrastructure, piggtback on events, etc.
|
| Meanwhile Linux seems to be doing quite well from where I sit.
| I'm not sure what activities are lacking around Linux that a
| more focused (and inevitably much leaner) organization would
| drive.
| RGamma wrote:
| The planet won't benefit from this.
|
| Agricultural overconsumption with a more efficient or open
| technology supply chain is still overconsumption.
| danuker wrote:
| How do you know it's overconsumption?
| RGamma wrote:
| Half the habitable land is farm land and farm land is
| ecologically dead (with pesticide use having damaging effects
| on the surroundings) and not available for carbon
| sequestration for instance.
|
| Also "livestock accounts for 77% of global farming land.
| While livestock takes up most of the world's agricultural
| land it only produces 18% of the world's calories and 37% of
| total protein"
|
| And the trend is growth..
|
| https://ourworldindata.org/land-use
| newsclues wrote:
| Is it impossible to use technology to make use of small
| plots of land to function as regenerative organic farms to
| sustainablely feed people?
| ahepp wrote:
| Won't improving ag tech improve the efficiency of farming
| land? And allow better ecological management?
| tome wrote:
| Beware Jevons paradox.
|
| https://en.wikipedia.org/wiki/Jevons_paradox
| RGamma wrote:
| Even 100% efficient agriculture is meaningless in the
| face of overburdening absolute demand.
|
| Raising efficiency and means of exploitation may also
| induce demand ("oh we're so eco-friendly").
|
| The point is: Life needs (contiguous) undisturbed
| wilderness.
|
| And ecological management? That this would even be
| necessary is testament to our fuckup, but yeah that might
| actually be topic's biggest benefit I suppose.
|
| Pre-industrialisation life managed itself just fine for
| millenia.
| wolverine876 wrote:
| > Pre-industrialisation life managed itself just fine for
| millenia.
|
| What do you mean by that, specifically? Clearly we
| benefit enormously from what has happened since,
| including food, shelter, peace, freedom, knowledge, etc.
| etc. I just got something called a vaccine, which
| protects me from a deadly disease. Someone stuck a needle
| in my arm, but they had figured out how to do that
| perfectly safely. The vaccine was driven to the provider,
| kept cold in refrigeration, and I also drove the provider
| after making prior arrangements via telecommunications.
| You're literate and reading this on a website using a
| computer, a vast collection of manufactured items ... You
| get the idea.
| RGamma wrote:
| I meant natural life. You know, animals/plants... Those
| things that inhabited this planet for millions of years
| before us.
|
| https://en.wikipedia.org/wiki/Life
|
| Christ, how far have things come
| wolverine876 wrote:
| I understand your point now. I didn't realize that your
| last sentence referred to human-managed 'wilderness'.
|
| Anyway, what is your solution? Starvation doesn't seem
| like an option.
| RGamma wrote:
| Why starvation? Is there nothing between being adequately
| fed and starvation?
| marcinzm wrote:
| So? The question isn't if it's better than some utopian ideal
| situation but if it's better than what we have now. If your
| approach to things is the former then every solution to every
| problem will fall short and nothing will ever change.
| RGamma wrote:
| In general I agree with "incremental progress is better than
| none".
|
| However this problem is not of a technological nature but a
| political/institutional one.
|
| If there had been a strong forward-looking consensus to keep
| agricultural ecosystem use in check, it would never have come
| to this point.
|
| As so often the free market moves first, society gets to
| clean up afterwards.
| bourgwaletariat wrote:
| Not unsurprising to me, I have a contrarian view to most of the
| comments here about this. This project is supported by, among
| others, https://www.farmfoundation.org/about-farm-
| foundation/board-o... which includes US Bank, McDonalds, John
| Deere... among others who tend to invite derision here.
|
| What this does is extract even _cheaper_ labor from the masses. 9
| in 10 people used to be farmers. Now it 's 1 in 300. I find it
| hard to believe we have a problem with productivity in this
| industry.
|
| The end game here is to further centralize the power structure
| into the corporations who already control most of the supply
| chain. Look at how they treat seed farmers around the world. They
| pay them pennies for seeds and then charge thousands of dollars
| for them on the global market.
|
| Again... I don't see it. I see the trees, but where's the forest?
| williesleg wrote:
| Is that why bill gates is buying up all the Midwestern farmland?
| walleeee wrote:
| If this interests you, check out Phenome Force, they do weekly
| webinars featuring the open source/DIY agtech tools people are
| building: https://phenome-force.github.io/PhenomeForce/
|
| We need more software/hardware engineers in open source ag. Be
| warned, you may need to live in a somewhat rural area, accept a
| modest paycheck, and occasionally get your hands dirty, but it's
| a lot more fun than writing code to shuffle forms or finances
| around imo
| waihtis wrote:
| What I've been very interested in lately is whether there's a way
| for us to enable local food production (local meaning on the
| individual/family scale) via some technological or business
| innovation. Maybe something along the lines of automated remote
| farming which would factor in the lack of local space to farm +
| time limitations.
|
| Something that concerns me personally is the globalistic nature
| of the food supply chain and just from a risk management
| perspective it would be great to push it into a more localized
| state. But I don't think a world where everybody moves to
| homesteading is realistic, quite the opposite.
|
| Just superficial pondering. If there's some nice initiatives /
| startups / other working on this would be keen to learn more
| about them.
| kickout wrote:
| Can't do it at the individual/family scale. Gotta go back
| thousands of years for that model. Population is too great
| (mostly enabled by highly scaled, highly efficient agriculture)
| openthc wrote:
| Take a look at spacebuckets ( eg:
| https://www.reddit.com/r/SpaceBuckets/ ) works awesome for
| cannabis -- but also: lettuce, herbs, cuke, growing aquaponic
| pineapple in the winter in Oregon, etc. You can get a bucket
| (or larger controlled envrironment) and control the whole thing
| via Pi and this thing is cool too --
| https://github.com/kizniche/Mycodo
|
| e: and we're working on this :)
| openthc wrote:
| This is promising; but in the Ag space there are 100s of
| providers all doing it their own way. The same problem is staring
| in the cannabis/hemp space too. We've been working for 5+ years
| to herd all these cats together -- and now another one (cue XKCD
| about standards). We'll likey join this initiative but, I'm
| concerned how it will work with the 100s of others who are way
| more interested in building their own walled garden, or saying
| "here's a standard API (ours!)" w/o any outside inputs.
|
| And @tomhoward on here brings up loads of good points -- in N
| farms we've seen N unique implementations ("bespoke") of
| monitoring, recording, measuring and pumps and processes and
| power-systems and all that.
| olafura wrote:
| For me Farmbot ( https://farm.bot/ ) is some of the most
| interesting thing happening in open source farming and they
| aren't apart of this initiative. None of the projects are really
| something your need a framework for.
|
| I think what some of the projects involved are doing is laudable
| but it's not really revolutionary.
|
| Then again I don't do farming though some of my family and
| friends of my family do.
| kickout wrote:
| I do farming. I'm intrigued by this concept, but am hesitant. I
| don't see any value add off the bat.
| olafura wrote:
| From my understanding how you can help farming with software.
|
| You have supercharging current methods which most of the
| projects in the OpenTeam initiative are doing which seems to
| be turning into the AgStack Foundation if I understand it
| correctly. Think adding smart sensors might be some of what
| they are planning with the framework and importantly all the
| planning and managing of farms which the strangely named
| FarmOs is doing ( I say strangely since it's not an OS ).
|
| The other is doing things with hardware and software that
| aren't mimicking or supercharging current methods but just
| implementing a new and more efficient way of doing things.
| Think the difference between making a perfect robot hand and
| making thing that grips. Both do the same thing but one is
| not trying to do the same things as the other. So here you
| have things like Farmbot that probably need so be split into
| separate stages of operation if it is going to scale at a
| farm field level.
|
| I feel like we are past the making a better tractor and other
| farm machinery phase and are moving into automating
| everything we can phase. Because the problem with our current
| processes is that they are stressing soil and the nature too
| much. By having diverse crops in the same field you both
| minimize the impact of soil, groundwater problems, salting
| and stuff like that, but also minimizing the risks in farming
| where you rely on futures commodity markets instead of having
| a wide balance of produce.
|
| But I'm no expert and haven't put much thought into this.
| Just want us to head in the right direction and make sure we
| invest in the right things.
| olafura wrote:
| Nice you are thinking about similar things like "autonomous
| weeding machines".
| peteradio wrote:
| That is gardening not farming.
| olafura wrote:
| You always have to prove things out on a small scale for it
| to work on a large scale. When I was in my early teen we had
| a summer program to plant vegetables. I do understand that
| it's not the same as large scale farming having grown up
| around farming but fundamentals are still similar.
|
| Yeah having stationary structures doesn't make sense in large
| scale farming but AUV with the tech that is in Farmbots makes
| a whole lot of sense.
|
| But I might be missing something. Also the farming I have
| experience is just in Iceland where things don't get that
| big. I've been around a lot of different tangential things to
| do with farming since my father side went from farming to
| construction. But I feel like a lot of the things are
| similar.
|
| But what I know most about is software and I am mostly
| judging things based on that and I'm really impressed with
| Farmbot and the choices they made.
| sigmaprimus wrote:
| This is great news, hopefully with enough heavy hitters backing
| this project it will succeed.
|
| I'm not a big fan of improving pesticide application techniques
| (one of the examples given in the article) as at the end of the
| day it is still pumping poison no matter how efficient but if it
| means less chemicals leeching into our food and environment, I
| suppose it's better than doing nothing.
|
| LifeTrac is an interesting Open Source project that might benifit
| from this foundational type of support.
|
| When it comes to agriculture, there is already a very large grass
| roots, open community of farmers and growers. Eg. Market
| gardeners, Seed sharers, Homesteaders even Hay farmers. I believe
| this group is primed to turn into a powerful societal movement
| but does require financial support to compete against the
| corporate giants that at present literally dominate the AG
| field(s).
| protomyth wrote:
| _This is great news, hopefully with enough heavy hitters
| backing this project it will succeed._
|
| I don't see any real agriculture heavy hitters (e.g. Cargill,
| ADM).
| sigmaprimus wrote:
| Bayer? Aka Monsanto? How about JD Tractors and the whole
| right to repair?
|
| But yeah it would be awesome if Cargil got onboard. They are
| into everything, I used to run multi purpose cables for Flir
| trafficon cameras that was made by a Cargil company. (FLIR
| could be a huge supporter too for that matter)
| nerdponx wrote:
| Hopefully we get some Open Hardware too.
| wokwokwok wrote:
| > "Just like an operating system, we feel there will be a whole
| universe of applications that can be built and consumed using
| AgStack," Johal added. "From pest prediction and crop nutrition
| to harvest management and improved supply-chain collaboration,
| the possibilities are endless."
|
| ...said AgStack executive director Sumer Johal according to
| venturebeat (1) in another meaningless statement that provided no
| concrete details.
|
| Their high level architecture (2) comfortably encompasses
| everything from ML to shells to security; "like an operating
| system" the press release claimed, careful to avoid saying they
| were actually building an operating system, because that would be
| daft.
|
| ...but who is Sumer Johal? Well, no one very interesting (3) it
| turns out, but he's been involved in agtech for some time...
|
| So... I guess I'm left puzzled?
|
| What does this have to do with the Linux foundation?
|
| Well, turns out the place to go to find out is... surprise, the
| Linux foundation:
|
| https://www.linuxfoundation.org/en/press-release/linux-found...
|
| "Through the AgStack Project, the Linux Foundation will provide
| valuable cohesion and development capacity to support shared,
| community-maintained infrastructure."
|
| Or something. You read it and decide for yourself; 20 different
| companies coming together to collaborate with completely
| different ideas of how and on what.
|
| Sounds like open office.
|
| Can't wait to see how it goes...
|
| [1] - https://venturebeat.com/2021/05/05/linux-foundation-
| launches... [2] - https://agstack.org/projects/ [3] -
| https://www.crunchbase.com/person/sumer-johal
| danuker wrote:
| Ugh, I can't select text on the page. I do it to read more
| easily.
| manifoldgeo wrote:
| I came here to say this! I highlight lines as I read pages to
| stay focused, and when highlighting is (purposely) broken like
| this, it's really frustrating.
| _skhan_ wrote:
| Along the same lines, there is https://farmos.org/
|
| It is a kind of like a CMS/ERP for agtech. I am using it for
| basic farm management purposes like inventorying equipment,
| chemicals, etc. It is built on Drupal which I personally do not
| like. Overall, the open source nature of the project allows
| anyone to contribute new modules.
|
| I was building my own app before I found it and am glad it's one
| less project I have to 20%
| wolverine876 wrote:
| FarmOS is included in AgStack under 'members and partners'.
| _skhan_ wrote:
| Thanks I didn't notice that!
| dementiev wrote:
| This is very needed for the industry. I'm a co-founder of agtech
| startup https://geopard.tech, we act as a platform and
| infrastructure for ag businesses (provide analytics and APIs) in
| the precision agriculture niche. When we created the company, it
| was the idea - to support agtech companies to launch their
| software faster/cheaper (our engine analyses yield, soil,
| topography, satellite, ground sensors, drone data and provides
| analytics on top of it). Before GeoPard we had another agtech
| company acquired by ag giant Bayer in 2015, then inside Bayer, we
| built Xarvio digital farming system. So, this is very needed, I
| know what I talk about. It takes usually minimum few years to
| launch solid agtech product.
|
| The biggest issue I see right now is where to get valid data.
| Model is nothing without a huge amount of validating datasets,
| which only have ag giants. They will not share the data so easy
| since all of them build their digital platforms and understand
| the value of data.
| lifeisstillgood wrote:
| Software has not eaten the world yet - not even reached the
| starters, it's just finished the bread roll.
|
| There is a tension between closed and open source here that is
| going to occur _in every industry, in every country_.
|
| And we shall all sit on the sidelines bemoaning the lack of
| standards ... unless ... err
|
| I have to admit I don't know how to build dynamic detail based
| standards that don't die in committee - how do we get YAML / JSON
| and not SOAP?
|
| I suspect it is best to start with a 100 Million dollars, and
| create open mailing lists for each industry, and invite the best
| of each industry to conferences each month.
| mastazi wrote:
| Unfortunately the article doesn't contain any link to the AgStack
| Foundation itself, so here it is: https://agstack.org/
| teruakohatu wrote:
| Having read that still don't know what the project really is. A
| venue for people and corporates to discuss open agtech and a
| source of funding for open agtech software?
| mastazi wrote:
| I think that it's just the same mechanism as the Linux
| Foundation itself, but specific for the AgTech sector.
|
| My basic understanding is that on one side you have companies
| who want to sponsor open source tech they depend on, and on
| the other side you have open source developement teams who
| would like to be supported; the Foundation facilitates
| interaction between these 2 sides.
| AlphaSite wrote:
| I think it's basically the CNCF for AgTech
| windthrown wrote:
| This was listed on the Project page:
|
| "The AgStack Foundation will not engage in building software
| applications but will instead focus on the software
| infrastructure (tools, frameworks, and models) that will be
| needed to build, manage and run applications by the members
| and users"
| mindentropy wrote:
| Maybe someone can help me, how can an individual benefit from
| Linux Foundation? Help means work/career opportunities, business
| opportunities, consulting opportunities. I want to have first
| mover advantage in AgStack.
| BJBBB wrote:
| Of interest to me because I have been doing agricultural process
| monitoring and production control systems for about 30 years. And
| most of my clients' systems are at least semi-custom and re-
| invent wheels for no other purpose other than to do it their way;
| that is, silos (pun not intended). But where NDAs and IP
| agreements allow, I have attempted to standardize some
| architectures.
|
| But was disappointing to see the way the LF is organizing this -
| no representation from the ag industry's heavy hitters and no
| specific and attainable goals.
|
| Should this be done by an Operating Systems organization? Other
| than centralized control and logistical systems, ag engineering
| is not the realm of microprocessors and operating systems, and
| code monkeys. Ag engineering is a world of hardware, micro-
| controllers, FSMs, and scheduler stacks.
|
| But then, if not the LF, whom has the organization to do this?
| is_true wrote:
| This should be done by the Food and Agriculture Organization
| that belongs to the UN. But well, you can't ask much to the
| United Bureaucrats Organization
| rektide wrote:
| LF is basically a deployable organizational model, typically
| taken advantage of by someone with an existing project or
| projects they want to release & collaborate on.
|
| there are blockchain, mainframe, embedded os projects,
| countless more, under LF.
|
| worth noting that Linux Foundation began as a merger of between
| Open Source Development Labs (who worked to push Linux adoption
| in enterprise) and the Free Standards Group (who worked to push
| open source standards) to standardize Linux. Only one of these
| groups started with an exclusive Linux focus, and that same
| group also focused on the enterprise & driving adoptability.
| jerrysievert wrote:
| > and that same group also focused on the enterprise &
| driving adoptability.
|
| well, sort of. there were a couple of half-assed pushes with
| things like linux for data centers, but mostly it was a data
| center filled with hardware that got very little use other
| than one asterisk system sitting in a corner, a stack of
| machines/disk that could be "checked out", but mostly got
| used for automated testing, and an NEC numa itanium machine
| that barely worked. add to that, projects that intel no
| longer wanted to support being shoved off, and you have a
| pretty good view of day to day life at the OSDL.
|
| source: worked there, doing day to day life at the OSDL.
| ghaff wrote:
| OSDL was almost certainly too focused on Linux vertical
| scalability at the time because that's what IBM and others
| were focused on. While things like NUMA optimizations became
| more broadly important over time (as those architectures
| became part of smaller and smaller systems), it's of course
| not how Linux primarily grew early on. The current LF
| executive director actually held that position at FSG when
| they merged.
| ghaff wrote:
| Despite the name, the Linux Foundation covers a whole lot more
| than Linux these days, including a variety of industry vertical
| orgs with both industry and vendor representation including
| (off the top of my head) motion picture, finance, healthcare,
| energy, automotive. So this is actually a pretty good fit. The
| general idea is to start out an org like this as essentially an
| MVP and iterate and grow over time.
| tomhoward wrote:
| Something like this is so sorely needed.
|
| I've been doing some work in ag-tech for the past few years
| (having previously worked in ISP/telco, general SME web/mobile
| development, then consumer travel tech).
|
| The tools available to farmers/growers for what should be quite
| basic things - i.e., web-connected weather stations and
| monitoring systems for soil moisture, frost alarms and irrigation
| control are terrible.
|
| The industry is full of small players who take a look and think
| "I know how to build stuff with [Arduino/Raspberry Pi/Zigbee
| etc], I can build an ag-tech monitoring/control product easily".
|
| So everyone builds a hardware product from scratch, then as a
| quick afterthought, a web app with an SQL database and Highcharts
| to show data graphs. You have an MVP within a few months, then a
| few paying customers in your local community, then suddenly your
| customers start asking for features you'd never thought of, like
| sensor inputs you didn't know existed, or combined displays of
| different kinds of data you'd never considered anyone would want,
| or needing it to be faster (SQL turns out to be really slow for
| this kind of data) or more reliable (bugfixing is hard when your
| devices are hundreds of miles away and connected via weak 3G/4G
| data links), and you realise your hardware and software
| architecture doesn't support any of this, and you'd have to
| completely start over to actually deliver something that
| customers really need, but you're out of money and energy.
|
| The result is a lot of farmers/growers dissatisfied/frustrated at
| never being able to get the monitoring systems they need (some of
| them having tried 3+ different vendors), and a lot of new
| companies trying to build new solutions and going bust.
|
| I've been thinking there needs to be some widely accepted open
| standards in the industry for hardware and software platforms, so
| solutions providers can avoid trying to re-invent everything and
| instead focus on integration of tried-and-true building blocks.
|
| If this initiative brings that about, it would be a big win for
| everyone in the industry.
| avip wrote:
| Wow. I worked in an agtech startup and this is _exactly_ how it
| went. Hopefully your comment stays on top for others to read.
| ahepp wrote:
| Are you aware of any promising companies or start ups in this
| area?
| dementiev wrote:
| I'll do a bit of self-marketing, but we at GeoPard Ag
| https://geopard.tech work on this. Have some big ag companies
| as clients
| rsj_hn wrote:
| You know what I'd like to see is there can be other non-dev
| support for these types of efforts. For example:
|
| * technical writers
|
| * security pentesting/code reviews
|
| * hosting and infrastructure support services for open source
| projects
|
| Pretty sure that there are a lot of people who would be happy
| to donate their time to opensource projects that benefit
| farmers, so there is a bigger opportunity for matchmaking here.
| dementiev wrote:
| That's the issue indeed. The entry threshold and the amount of
| minimum needed features for agtech products are very high.
| Moreover, the seasonality of ag business makes the situation
| for agtech startups even more difficult (you can usually sign
| new test clients only in between ag seasons)
| void_mint wrote:
| The best work I've ever done was for one of the biggest
| energy/agg companies in the world. They wanted an outside
| contractor to build something from scratch and ignore their
| normal corporate bureaucracy. They thought it was insane how
| much better the system we (I) built for them was than their
| normal in house tooling. The crazy part was the solutions were
| mostly just normal cloud tech. Postgres, DynamoDB, some AWS
| tools. They paid over a million dollars (nothing to them) for a
| set of tools that weren't technically advanced at all.
|
| In my experience, the problems are a result of the manufactured
| constraints on the physical hardware/sensor devices. Mountings
| and power and connectivity. Receiving data from an array of
| devices into a shared storage system for analysis is a well
| solved problem. Receiving data from multiple sensors on a fixed
| interval, when the sensors may be made by different
| companies/work totally differently, is where the complexity
| lives. Combined with each company trying to build their own
| awful closed source proprietary data system on top of their
| sensors, you've got a really terrible time.
|
| > SQL turns out to be really slow for this kind of data
|
| I think this is just poor modeling. SQL is just fine for the
| work you're talking about.
| ethbr0 wrote:
| > _Combined with each company trying to build their own awful
| closed source proprietary data system on top of their
| sensors, you 've got a really terrible time._
|
| The more I think about right to repair, the more I become
| convinced it's a symptom of hazy interface specifications.
|
| Radical idea: Ban sensor / actuator companies from building
| software on top of them in-house.
|
| They're welcome to offer a turn-key solution to market, but
| it must (1) have hardware and software built by two separate,
| independent companies & (2) publish its interface specs,
| between those two companies, to all customers or end users.
|
| Things would cost more. But I'm not convinced this would be a
| worse world, in aggregate.
| abraae wrote:
| > I think this is just poor modeling. SQL is just fine for
| the work you're talking about.
|
| I'm as big a booster of good old SQL as anyone, but there's a
| lot to be said for more targeted time series solutions when
| it comes to sensors.
|
| I'm working on a platform for monitoring water water tank
| levels. It slices Grafana and influxdb horizontally to share
| the resources between multiple users and multiple tanks.
|
| The productivity of such a stack is high, when it comes to
| getting beautifully rendered, interactive graphs of e.g
| stacked water levels. And with influxdb flux language, you
| can write joins that join data from the time series database
| and the rdbms (for more reference data, like the names and
| calibration data of individual tanks).
|
| Yes you can do anything with SQL but there's a reason for the
| presence of dedicated time series databases.
| void_mint wrote:
| > I'm as big a booster of good old SQL as anyone, but
| there's a lot to be said for more targeted time series
| solutions when it comes to sensors.
|
| https://www.timescale.com/
|
| Sensors aren't really different from any other timeseries
| data.
|
| > The productivity of such a stack is high, when it comes
| to getting beautifully rendered, interactive graphs of e.g
| stacked water levels. And with influxdb flux language, you
| can write joins that join data from the time series
| database and the rdbms (for more reference data, like the
| names and calibration data of individual tanks).
|
| Your productivity being high with a given tech stack does
| not disqualify an alternative tech stack from having
| equally high (or much higher) productivity for equally
| trained users.
|
| > Yes you can do anything with SQL but there's a reason for
| the presence of dedicated time series databases.
|
| The reason you're describing is "marketing"
| abraae wrote:
| > Your productivity being high with a given tech stack
| does not disqualify an alternative tech stack from having
| equally high (or much higher) productivity for equally
| trained users.
|
| Try implementing classic timescale features like down
| sampling in your straight RDBMS.
|
| Certainly you can do it, just as you can build a house
| with a hammer and nails rather than a nail gun.
|
| But you'll spend lots of time building undifferentiated
| infrastructure that you could have got out of the box.
| void_mint wrote:
| https://blog.timescale.com/blog/how-to-proactively-
| manage-lo...
| walleeee wrote:
| There is a bit of progress towards open standards: e.g.,
| MIAPPE, BrAPI. But you're right, we have a long way to go.
| Programmers and software/hardware engineers are sorely needed
| but ag struggles to attract them, and the startup model is not
| very well suited for the space imo- we need to build a
| collaborative ecosystem of open source tooling that farmers,
| biologists, breeders, and others in ag/plant sciences can hack
| for their particular use case
|
| Check out Phenome Force, they do weekly webinars featuring the
| open source/DIY tools people are building: https://phenome-
| force.github.io/PhenomeForce/
| bshipp wrote:
| You appear to have had the exact same experience as I have. I
| work in the fresh vegetable side of things and the tools that
| are available are completely closed source and locked in. Even
| silly things like humidity controls and whatnot. there's so
| much potential for the ag sector to benefit from all these open
| data sources and systems.
| krapht wrote:
| You can't make money selling hardware with open API, though.
| It'll get cloned and manufactured in China, and people buying
| in bulk will naturally choose the cheapest option.
|
| Nobody makes money in open-source selling software, either.
| Everything is either consulting, or SAAS.
| tracyhenry wrote:
| Can you elaborate on the kind of data and queries that SQL is
| slow for?
| openthc wrote:
| Likely the sensor data being stuffed into a "standard" SQL
| schema -- loads of these bespoke solutions aren't fully
| dialed in with tools like timescaleDB, or Prometheus for
| these metrics. Even with slower (eg 240s interval) sensors
| the data builds up -- and slows the systems (w/o indexes).
| void_mint wrote:
| The problem that arises with a lot of these "pull data from
| sensors, pump it into a database" is schemas and data
| integrity have to be kind of a second-class problem behind
| storage. When you can't push an update to whatever is
| ingesting data, and that ingestion tool is also ingesting
| with an invalid format, you can't just ignore the data (or
| fix the problem). So your store has to accommodate semi
| structured and unstructured data gracefully.
|
| I do not agree that SQL is "slow" for these types of
| problems. I've built a number of systems that support this
| issue effectively. You _could_ use a tool that has
| schemaless/unstructured data as a first-class feature, but if
| your goal is to reduce complexity a Postgres instance is just
| fine. As with all data projects, indexing is important and
| needs to be thoughtful (from the beginning). For sensor data,
| it's also a good idea to think about data retention and
| removal policies immediately (keep your metrics/aggregates,
| move raw data to cold storage after a while).
___________________________________________________________________
(page generated 2021-05-08 23:00 UTC)