aflinik

Does that imply that with enough effort spent on fine-tuning the configuration, other LLM runners can achieve similar results?

sure. but to be fair, I don't see a reason why AI couldn't generate a non-random juxtaposition

Looks like a juxtaposition to me.

Can you give me some examples of an actual creative output from a human that wasn't coached into it or random juxtaposition?

Can you post some links to other similar projects you've seen? I'd love to compare different approaches

Not sure about the exact same active substance, but Amanita muscaria is the obvious candidate. It's also commonly shown as part of the imagery in stories involving tiny people: the Smurfs, Super Mario (it's the power-up that makes Mario bigger/smaller), Fantasia, Alice in Wonderland, and so on.

It triggers for me on trains too, so I think it's just accelerometer + location

This is a really inspiring project and exactly the type of content I'm looking for on Hacker News.

A bit surprising that so many people in the comments would rather see links to cheap temu polaroid knockoffs.

There has been a similar project developed in Poland already. (https://en.media.pkobp.pl/78483-strategic-partnership-betwee...) In practice it's not much more than government-branded version of Google Cloud Platform and Microsoft Azure. So far it serves well as a marketing vehicle for a handful of the biggest corporations, but it's barely used by anyone.

I can see it could make sense as a solution to some particular problems though – European regulations often forbid banks from processing/storing customer data in other countries, so even though the tech is provided by the American tech giants, having everything hosted locally makes it possible for local financial services to finally move away from hosting everything on premises.

Wouldn't it make more sense for them to just take over Hulu? They are going to have 60% equity quite soon anyway

Not a book, but you might like Dirty Money series on Netflix.

I totally agree with you on the mandatory part, I’d hope it would be widely accepted that opt-in is the way to go in such cases.

Although I need to point out there’s a huge difference between what people say vs what they actually do (see https://www.nngroup.com/articles/first-rule-of-usability-don...) and I can’t imagine an effective product development process that ignores the actual usage data.

Transcriptions are not really the issue here, the cost of freelance transcribers is relatively low. It is privacy that makes it so hard, most of the call center calls need to have some kind of user authentication, which means they would need to be anonymized prior to being transcribed and used as a training material.

I’d say all of those examples show that you need to be first to the actual market, not just first or first to _some_ market

Having it learn on human games was just a way of speeding up the initialization process before running reinforcement learning, it didn't limit the state tree that was being searched later on.

Being a Pole, I wish more people understood that. :(

We're in the process of dismantling our democracy by removing all of the checks you mentioned, while supporters of the ruling party argue that democratically elected majority is within full rights to do it.

Why Java only?

That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node.

I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture.

Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.

Although it's meant to be sarcastic, I believe it nicely exposes typical things developers used to argue about back then, not that different from modern arguments about JS vs compiled-to-js, elixir vs erlang, GC vs manual memory management, etc.

Anybody knows some more serious piece from those times that would show the actual arguments of, say, PASCAL opponents?

It's included in this collection: http://www.amazon.com/Imaginary-Magnitude-Stanislaw-Lem/dp/0...

That's far from true, I bought my FiftyThree Pencil at Apple Store.

According to this quiz, you can either have small guaranteed impact or bet on something bigger while accepting you might fail.

I wonder what's their take on bootstrapped startups, that have potential to grow exponentially but don't rush it valley-style. Biggest long-running tech companies had positive revenue since very early in their life (if not day 1).

It's like saying any information printed on paper is useless, because people hate flyers.

Think of it as of seeing URL printed on the wall (or hidden in QR-code), just easier to use if you actually want to.

It's not spamming notification center. Whenever the beacon signal is heard the information about it is shown in Chrome widget, but you still have to manually go there to see it. If you ignore it and move away from the beacon it will simply disappear.

We're doing sensor-fusion trying to use as much data as possible coming from different sources, so besides RSSI from beacons there's also accelerometer, magnetometer, etc. Lots of non-trivial maths to combine that into a robust model, but results are getting more and more incredible. :)

I think I like your musical taste.

If you're curious about the Commodore 64 thing, the speaker is launching a series of screencasts as well: http://64bites.com/

(disclaimer: the author is my friend, but still highly recommended!)

I remember React devs saying they always remember about that, so the whole library is designed to be easily detachable from the DOM, or whatever renderer you might be using. They're also kind of proving that now with ReactNative, and knowing what's coming in the next React versions it's gonna be even better.

Nice thing about React is that even after you remove the Virtual DOM it still encourages a really good model of programming and makes it effortless to build your app.

Just compare number of well-known production apps written using React & Angular.

Don't see how that's a bad thing, nobody forces you to use it, and odds are some nice ideas will get validated here and more popular frameworks will adopt them. Think how React influenced the changes in rendering models of Ember, Angular, etc.

Always baffles me how HN crowd can at the same time revere Lean/Agile mindset, and at the same time despise the same principles applied to the tools ecosystem. To me it's obvious that to make progress of any kind multiple attempts are needed. Naturally only few of all those experiments will survive, the thing is nobody knows which ones.