olafura

It keeps on being weird

Wonder if it's a Gemini model because it was getting stuck on a rebase command because of vim being a non-interactive editor

Was actually pulling on a similar thread as I saw announcement so I integrated it just for fun. Have been only running this on my Framework Desktop but should be runnable elsewhere https://github.com/olafura/gemma-4-mic-transcribe

Unless I'm totally misunderstanding something it's not xml but special tokens for the tokenizer someone smarter than me might know https://medium.com/@nisarg.nargund/why-special-tokens-matter...

Looks like it's not open source: https://www.alibabacloud.com/help/en/model-studio/qwen-omni#...

You can just use git to clone the code

If you want we can schedule a quick video call. Just curious about the problems you are facing.

I still don't understand this. If you are big enough then you get Amazon to make an official sdk, if you aren't then what exactly are you looking for?

The official aws cli used to talk to the soap interface and used regex instead of actually doing correct error handling and that was used by so many tools. Even though it used to break horrible.

It's quite a niche you are talking about, not big enough to debug open source code but still big enough to require SLA for SDK and not being able to talk Amazon into creating it. It's generated code, it's not rocket science.

What I have experienced is that software licence, where you are sending data to, where you are hosting it and having access to audit the code has usually been a bigger concern.

But then again big organisations often have really specific concerns. So I'm not doubting your statement it's just that I have never heard it before.

What are you talking about, there has been a AWS client forever and I've never had a problem. It's not something you really need an official sdk for they are anyway often just reference because you might want different performance characteristics.

https://hex.pm/packages/ex_aws https://hex.pm/packages/ex_aws_s3

I've usually not seen more than 3 or so official SDK for most services and there are a lot more programming languages than that. For example Microsoft's Graph API doesn't have an official Ruby client, they have one that sort of works.

One example given in the article is Erlang VM which maps a lot better to modern processors.

We currently have a problem where we can't have thousands of cores because, even today, so much code is designed to be fast on one core.

We really have to move the asynchronous programming because synchronizing async hardware is both complex and inefficient.

RISC V is probably going to help since it allows for a lot of experimentation.

Very exciting, there are so many things happening in the Elixir Machine Learning space, with all of it focusing on being easy to deploy and test yourself.

I just love that you can create robust ML services. Which for me, isn't as easy to do in Python, even though I've created async service with core Tornado before asyncio was a thing.

I don't understand how this is a difference between stacked diffs and feature branches. Github allows you to use feature branches. I can see there might be some convenience with tooling

So the question is why a project created in a language that has been around since before the devices being emulated are more mature than ones in a language that is 8 years old?

Sorry to be so snarky. It probably depends on people's time working on it and their familiarity with async processes. This is an inherent problem with any media like that. With sound, it's primarily that it can't come before the image but can lag behind the image. Stuff like this.

I don't think any programming language is going help with that because it's how we perceive things, not just how correct your code is.

I believe Thunderbird has the strongest ties to LibreOffice. https://wiki.documentfoundation.org/Ideas_for_the_integratio...

They should link to this from the amazon page: https://ai.meta.com/llama/use-policy/

I feel like the biggest problem is most COBOL code is heavily tied to the mainframe it's running on [1]. There are already ways of compiling COBOL code with a modern compiler [2].

There are also multiple other translation projects:

https://dockyard.com/blog/2021/08/10/what-if-coboltoelixir

https://www.microfocus.com/en-us/products/visual-cobol/overv...

[1] https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-cobol... [2] https://gnucobol.sourceforge.io/

Where is the source code, I'm confused. Maybe after the presentation?

I really like Lit. It makes you in most cases write better reusable components, though you should still check all the properties to see if they are too reliant on some property.

We started using it because we knew it could be embedded into any other framework, we are using two others in the company. But are starting to use it for SPA also. Glad to see it growing quickly.

Thinking about possibly reworking our SPA to use Phoenix LiveView most of the abstractions are there already.

There are no links to news articles and they are nowhere to be found. There is an obvious trademark problem which makes it harder to search for the product.

Looks really cheap and if I understand the technology correctly would only have a small area that you can see correctly through.

Why are we allowing scams on this site. Isn't there any check?

I like that we have something that will work at such a low bandwidth. But it does sound like real audio with the wobbly ( robotic ) tone of voice is back.

Regarding the my browser isn't supported they are just trying to have it optimized and in the manner that they see as the way forward. You should still be able to send this as data with webrtc. If there was no way of implementing it without this api then it would be different.

Refreshingly honest about the video quality you should expect in the main promo video. Typical problems like dynamic range, color profile, light bleed and tracking problems with the top of the head being cut off at one point. Pretty typical unless you spend more money on your drone or camera equipment. There are so many companies that fake the footage or pick much easier shooting locations.

Here an unoffical implementation https://github.com/Janspiry/Image-Super-Resolution-via-Itera...

Imagine a game using this tech, you could render a game in a lower resolution and possible get a better looking game. But then again they aren't yet dealing with temporal data.

In the previous discussion https://news.ycombinator.com/item?id=27858893 they mentioned that it was only class conditional but it also seems to work on unconditional data.

Years here

My biggest problem is with hardware/software combos bolted to something like tractors.

When I was working as a surveyor for my families construction company, we gradually transitioned to having surveying capabilities added to our machines.

And I can tell you they are overpriced pieces of garbage that still work but boy they are backwards. There is some really cool tech but it's obscured by really old buggy software.

The problem with bolting things to existing equipment is you are going to face so many hurdles that is why only a certain type of companies even try to do it. Those include being allowed to integrate with the hardware. Usually not companies that developers interested in elegant solutions. Not that I don't think people that work for those companies can't do interesting things they are usually hindered in doing so.

That is why most companies trying to innovate go the route of building things themselves.

That is also where you would find people that believe in open source that want to do interesting things.

Why bolt things to a tractors whey you can just mod something like a 4x4 vehicle.

I'm a person that would not build a farmbot or probably work much on it in my free time. Have plenty of side projects. But I think their tech is cool and their methodology I feel is right. So I would probably join them as a developer if things lined up. I can't say the same for any of the other projects.

What you need to look out for is when developers are excited about something. It doesn't mean it's the right solution but it's really good starting point.

Nice you are thinking about similar things like "autonomous weeding machines".

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.

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.

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.