AI is like TV in that old saying: AI makes the smart ones smarter and the dumb ones dumber.

LLMs can both help you advance your knowledge and do your homework (preventing you from learning).

I am trying to build a simulation that lets a simulated organism come up with its own small language, purely learned from sensory input: https://github.com/JoergStrebel/VirtualZoo/blob/main/compute... I would like to implement the ideas put forward by Stevan Harnad in his symbol grounding problem paper (Harnad, 1990).

Hi - This sounds interesting and is an area that has fascinated me for quite some time. I think it is possible to build an agent whose intelligence emerges from preserving viability, learning which perceptions/actions are worth their metabolic cost, and grounding concepts in sensorimotor experience. I have been inspired by the ideas of Karl Friston, Anil Seth and the like. Following!

Banking apps are the deal-breaker for me. I only do business with banks that offer alternative ways of securing transactions e.g. eTan / ChipTAN / PhotoTAN with a separate reader / generator (see https://www.bsi.bund.de/EN/Themen/Verbraucherinnen-und-Verbr...). This is probably a pretty European thing to do, but at least it avoids being locked in and being tracked.

I'm happy that my bank (still) allows me to have both a stand-alone reader and a mobile app to authenticate. Because if you lose your authentication device, a lot of things suddenly get a lot harder.

I also tried to use an old phone as a backup device. However, most authentication apps only allow it to be installed on a single device.

I did that too (in Austria) for a long time. Fortunately my Bank (Erste Bank / Sparkasse) fully (almost fully, no nfc pay, since it depends on GPay) supports GrapheneOS now

But you would already have to have shell access to the system to execute those commands, right?

Like it says in the preamble on the site, don't think of this as a collection of exploits, but rather as a compendium of knowledge about escalation techniques for use in emergencies.

I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..

GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..

But that sort of access is only a social engineer away. People still click on stuff in emails, or run commands because a computer says so.

...or something that runs CGI commands. Bash scripts are like the glue of the internet, and many of them are poorly-written. Tons of stuff still runs on PHP or relies on little Python cron jobs behind the scenes. A lot of the way this stuff works depends on being able to chain vulns together...an unescaped query to a database that gets piped to a nightly cron job to sync or backup something becomes an attack vector.

You might have WiFi access to mtr, allowing you to traceroute as root but not launch a shell or read files. But with these tools you can escalate.

A sterotypical example would be to have an SUID command that does something the user couldn't normally do, and can be tricked into launching one of these other commands.

A less typical example is giving a user restricted shell access where they only have access to a few binaries. I think people used to do access control like that in the 90s, but people stopped because its very hard to get right. Its still a very common challenge in CTFs because its very easy to adjust the skill level and come up with new variations.

Not just shell access, but the server would need to be configured to also enable your user to run any of these binaries as root (such as an administrator putting them in the sudoers file).

So they're a pretty niche attack vector, and oftentimes crop up as a result of lazy/incompetent sysadmins.

An adult is a person who managed to leave childhood behind, especially in his thoughts. It's the independence of and emancipation from childhood.

I also love it. Finally, I am no longer constrained by syntax errors or forgotten API details. I can focus on the feature. It's like taking programming to a higher level - programming in English (instead of Java).

That's it for me too. I'm churning through a multi-year backlog and can finally implement my ideas for which there just wasn't time before.

Same. As long as we are reading everything we're submitting upstream and working towards either cleaning up slop or cataloguing them as debt, it's fine.

How does your framework compare to spec-driven development e.g. https://github.com/github/spec-kit? In my experience, spec-kit produces a lot of markdown files and little source code.

Very similar, in particular the first phase is lot of markdown and no code too, but spec-kit is clearly more matrue and wide in features and support, while my scaffold is newborn and supports just Claude Code.

I feel that my scaffold is more adherent to old-style waterfall, for example it begins with the definition of the stakeholders, and take advantage of the less adopted practice to maintain assumptions and constraints, not just user stories and requirements.

A big difference is that I have introduced decisions, that are not just design decision, but also coding decisions: after the initial requirement elicitation phase whenever the agent needs to decide on approach or estabilish a pattern, that is crystallised in a decision artifact, and they are indexed in a way that future coding sessions will automatically inject the relevant decisions in their context. Another difference is that when using the scaffold you can tell high level goals, and if the project is complex enough the design will propose a split in multiple components. Every component can be seen as a separtate codebase, with different stack and procedures. In this way you obtain a mono-repo, but with a shared requirement/design that helps a lot in the change management, because sometime changes will affect several components, and without the shared requirements and design it will be pretty hard to automate.

Death will soon realize that he messed with the wrong man.

A very nice video. It shows that computer games are glamorous on the outside, but once you look behind the scenes, they just look like normal software. I was also surprised to hear that the team did not only rely on computer graphics textbook algorithms, but built their own pathfinding algorithm in a pragmatic manner.

If you have to ask why this is not for you. Why climb a mountain that’s already been climbed hundreds of times? For the challenge.

Well, in a world of finite resources, I think I would need a better reason to invest time into this topic than just "for the challenge". I mean I just think that I have ample opportunities to do something more sensible with my time. Climbing a mountain at least gives you bragging rights; I don't think a bootable floppy disk is impressing anyone these days.

> I don't think a bootable floppy disk is impressing anyone these days.

Scroll up