e12e

Is it run/developed by Tieto (Vivicta)?

Ed: I'm guessing yes?

https://vayla.fi/-/new-public-transportation-travel-card-sys...

Yes, it's a single point of failure by design - but has been pretty stable mostly - with this and a previous attack in June being exceptions.

The identity portal is administered by the department for digital services, but hosted at a commercial provider, Vivicta (formerly TietoEvery, formerly Tieto and Every - Consulting companies from Finland and Norway).

https://www.agilitaspe.com/index.php?id=136

From TFA:

> Det har siden kl. 01 mandag 3. august pågått et tjenestenektangrep (DDoS) som rammer ID-porten som driftes hos Digdirs driftspartner Vivicta.

> Since 0100 hours Monday August 31st there's been an ongoing DDoS attack which affects the ID-Portal which is run/hosted by DepDig's (Department of digital services') service provider Vivicta.

(My translation)

Ed: just realized Vivicta is TietoEvery with a haircut and new shoes:

https://www.agilitaspe.com/index.php?id=136

> People that previously have barely any experience in tech, now being hired in AI startups because they are good bullshitters.

I like the symmetry of people being unable to detect "skill" in people who are great at manipulating language and in LLMs who are also great at manipulating language.

Actually the stack is wrong here, after pushing two words, the sequence should be:

    Forth
    I

I don't know what the author's native language is, but I assume it's something I'd need machine translation for anyway. Having it in good (if not Nobel prize level great) English is much easier - and will probably be easier to find again via search.

There's a lot of well reasoned, but pretty caustic, developer blog notes for the project.

Refreshing breath of honest air, imnho. I don't agree with the author in all things, but I enjoy how well and directly they express their viewpoints.

See also: https://ansel.photos/en/

Seems odd that you wouldn't comment on the existing issue, or open a PR?

https://github.com/bholmesdev/hubble.md/issues/176

Looks like you use it explicitly?

https://github.com/sbcl/sbcl/tree/master/contrib/sb-simd

A different way to say the same: in forth, words get pushed on the stack, and popped from the stack by words that take arguments:

    code           stack
    I Forth love

    Forth love     I

    love           I
                   Forth

    ; love presumably pops
    ; subject, object args
    ; from stack - and does something 
    ; perhaps prints as side effect

> I'm merely noting that your argument that "training+input=>output is the problem" applies to humans.

I'm not sure I ever said that it was a problem.

I also never meant to say that sampling across the model (formed by training) based on input couldn't produce novel token sequences.

As for human vs LLM - my argument would be that while trained on a large corpus, the models are poor in experience and "sensory input" - their training so different from growing up - that even if we could model humans as LLMs - the gap between current LLMs and "human" LLMs remain a wide one.

More to the point - I believe the current generation of LLMs are way too sensitive to input (prompt, system prompt, context/RAG) - precisely because they're still too narrowly trained, and also aligned to weigh input heavily.

What we have today are models that work well with language (generate, transform, translate) - not so great on complex tasks - because they're still generating next probable token.

If you shuffle a deck of cards, you likely have a novel sequence of cards. I'm not sure how that is relevant?

I think there are quite fundamental differences to the LLM model equivalent to an adult human mind and current LLMs (even accepting an LLM can model a human brain, which I don't think is a given - but I also don't think it's impossible).

The details matter (training set, full context). I doubt our current LLMs knows what smelling cut grass on a wet morning feels like, or how the stomach flutters on a first kiss - even if they have "read" tens to hundreds of attempts at describing such things.

You're essentially suggesting we play Turing's Guessing Game; if your LLM can guess my response to any prompt - then it can be said to have modeled how I would reply to those prompts. Expand the prompts far enough, and you could reasonably argue the LLM models me.

Doesn't the LLM still output the next most probable token (modulus heat/desired variation) according to its model? Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model?

Aww, I thought this might be a literate programming wrapper around grotesque yaml action programming...

I think orms are typically fine. Something like rails can even play reasonably well with legacy databases (but you might need to create a view or two to rename columns names that collide with "magic column names").

There are reasonable arguments for leaving most to the db; effectively exposing some VIEWs and FUNCTIONs as the application interface for any and all bindings. Like legacy java and greenfield php for example.

I'd say it's different work rather than strictly more work.

Been gone a while?

https://apple.stackexchange.com/questions/465150/make-shortc...

Great article that articulates some sentiments that have been percolating in the back of my mind, as well.

Nice write-up! I saw some earlier posts were submitted here, but not that one - so I tried submitting it:

https://news.ycombinator.com/item?id=48686947

But you couldn't yourself email the agent from your phone (for example) and receive a response via email?

I can't immediately think of what a useful shader test would look like (beyond perhaps, shader doesn't crash program) - if this is something worth discussing, it would probably be useful to see some real world shader code; perhaps especially two versions of the same shader as it evolve.

I don't generally test css code to check that a background is now indeed set to "a more mauvey shade of pinky-russet" after a change - but I might want to.

I might at least want to run a test with browser automation to check that any text is readable on the background.

I could at least find an example of looking at the rendered page for text (as opposed to in the DOM); Google AI had some ideas of how to check the contrast in a screenshot - but no idea if that would actually work as written.

https://medium.com/@dzianisv/vibe-engineering-testing-browse...

https://share.google/aimode/mW8ClhqGppfpovRrE

I'm not familiar with shaders and game engines, so I'm not sure what you are saying.

I had a quick look at godot tests, and seems to me they cover some parts of the shaders?

Anyway, I was more wondering who/how people are dogmatic about TDD, and manage to leave out one out of three core concepts from red/green/refactor ?

> TDD dogma of only writing code to fix broken tests.

Isn't red-green-refactor pretty ingrained in TDD?

Only write code to make a failing test pass; then refactor while making sure the tests still pass?

Then write a test that fails, repeat?

Looks like op mostly a rehash of the linked Wired story?

https://www.wired.com/2002/02/mitnick-meets-his-pigeon/

https://archive.is/oMcKd

Having read and enjoyed ghost in the wires (and at some point all of mitnicks books) - I still enjoy the infamous takedown movie. I think it still shows a lot of mindset around social engineering - and realistic holes in security measures. I do understand why a lot of people were pissed off, though.

Ed: https://www.imdb.com/title/tt0159784/

Ed2: can't recall if I ever got around to reading takedown - I think I did. Much prefer ghost in the wires.

If that tickled you, I also recommend "The New New Thing" by Michael M. Lewis.

Not from off state, though? Granted I still expect the iphone to boot quicker than 20 seconds.

(2010)?

... Via netboot.xyz?

https://netboot.xyz/docs/selfhosting/