Seems to be based on https://github.com/swaruplab/operon as evidenced by the authorization dialog and https://x.com/testingcatalog/status/2037684573161783373 .

Mostly targeted at life sciences - e.g. integration for FDA, PubMed, genomics databases but no ACM / IEEE as far as I can tell.

Edit: arXiv search seems to be supported - but not Google Scholar etc. So, this tool is of little use for most researchers outside life sciences.

Edit 2: Quick walkthrough: the AppImage starts a browser window with an onboarding wizard and a chat interface. It suggests a few things one might do at the start of a research project - e.g. do a quick literature review. When I chose that option, wrote Python scripts that used MCP calls to do arXiv searches. Stayed seemingly stuck there for a few minutes not returning anything. Then:

> The free-text search returned too much noise

Claude decided to choose a certain paper as a starting point for further research. Shortly afterwards:

> That DOI resolved to the wrong paper. Let me find the correct anchor papers by title/author search directly.

Then it meandered a few more minutes doing research and creating a citation graph (that it did not show to me).

> I have a complete picture. Let me verify the key DOIs resolve and then write the review.

Then:

> The lint flags em-dash overuse. Let me reduce them, then save.

Then: a nice but verbose literature overview of my chosen topic

BUT it includes at least one hallucinated reference!

P.S.: What does this mean?

  [reviewer] verifier_mode=default-on downgraded to off: pro subscription tier, autoReviewer withheld (frame=f2a81cb2)

For reference: it's called Kernighan's Law, and can be found in the Second Edition of "The Elements of Programming Style", page 10 [1].

The original phrasing is:

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

[1] https://archive.org/details/the-elements-of-programming-styl...

Reminds me of the old adage: don't try to be too smart when writing code. Otherwise, dumber people - including your future self - will have trouble working with it.

Gergely Orosz did an interview with them in 2024:

https://newsletter.pragmaticengineer.com/p/twisting-the-rule...

> "Cast iron and carbon steel have nearly identical thermal conductivity (~52 W/m·K), which surprises most people."

is unsourced. And the precise "~52" is quite misleading - Wikipedia and online sources report thermal conductivities in the range of ~30-50¹.

Also:

> "Critically, whipped egg white foam drainage follows a hyperbolic saturation curve: v = V × t / (B + t), where V is the maximum drained volume and B is the drainage half-life (Lomakina & Mikova, 2006)."

As far as I can tell, the article² (cited twice for this claim) does not contain any equations modelling drainage over time, and especially not this equation or the term "hyperbolic".

So, it seems that you cannot really trust the sources the author's LLM included. For me, that means that I cannot trust any of the other claims in the article (or the author in general).

¹) https://en.wikipedia.org/wiki/List_of_thermal_conductivities

²) https://www.agriculturejournals.cz/pdfs/cjf/2006/03/02.pdf

> " Ovalbumin coagulates irreversibly at 80°C (Weijers et al., 2003), permanently setting the foam structure.",

and the paper by Weijers et al. says:

> "A strong temperature dependence on the reaction rate was observed. At 80°C, half of the protein was denatured and aggregated in less than 2 min (half-time, th), while at 68.5°C this took approximately 6 h."

So, the citation is generally true-ish although a little bit imprecise.

At which temperature range Ovalbumin coagulates seems quite irrelevant for the whole article, however. To me it's unnecessary fluff, others might like that kind of detail.

(This does not imply anything regarding the article as a whole - it's just one thing I checked.)

My own experience with flipped classrooms (which seems to be shared by quite a few people who have tried it out): they only work well if all students actually read/watch the materials beforehand. In small, advanced courses, intrinsic motivation may be sufficient - but in most cases you need some extrinsic coercion - such as a mandatory quiz about the materials or hand-written lecture notes that need to be shown at each in-person session.

With AI, some people don't watch the lectures but let ChatGPT give them a summary which they submit. Then these people poison your in-person session with their lack of knowledge and motivation.

Not sure what the issue between them and Adafruit is. However, people over on Reddit¹ claim that Flux.ai is a little bit scummy. They push users into a beginner trial ($5/month) and then silently charge for usage per token - up to $100 per month.

Oh, they also claim that they have "the world's largest community-driven public library of Adafruit products, including footprints, symbols, datasheets, and simulation models"². I wonder whether they designed these themselves or whether they use existing ones. Could not easily find licenses info.

¹) https://www.reddit.com/r/PCB/comments/18o5zfo/thoughts_on_fl...

²) https://www.flux.ai/sitemap/manufacturers/adafruit

(I'm not sure whether I agree with the commentator that a SE license would be that helpful in practice.)

(It is obvious that one cannot directly derive the exact input - but one can derive potential inputs and then use other means to find the exact one.)

Netmux (2019): Hash Crack: Password Cracking Manual¹

James Leyte-Vidal (2024): Ethical Password Cracking: decode passwords using John the Ripper, hashcat, and advanced methods for password breaking²

Daniel W. Dieterle (2024): Password Cracking with Kali Linux³

¹) https://www.amazon.com/gp/product/1793458618

²) https://www.amazon.com/Ethical-Password-Cracking-passwords-a...

³) https://www.oreilly.com/library/view/password-cracking-with/...

> "Then there is also the fact that having a fully-fledged graphical desktop environment running in the background at all times is not quite optimal to say the least. 99 percent of the time when cracking passwords, you will be staring at a black terminal filled with white text, so using Windows, which is especially GUI-heavy, is usually impractical unless you are specifically testing something or showcasing some process."

I am reasonably sure that the Windows UI has rather little practical effect on hashcat's speed, and this thread implies the same: https://hashcat.net/forum/archive/index.php?thread-8958.html Also, 99 percent of the time when cracking passwords, I am not staring at a black terminal filled with white text.

(I am generally taking it a little bit personally when the author directly addresses me and tells me what I am probably thinking or doing.)

> "Behind a hash function are a series of complicated mathematical operations that make deriving the input from the output literally impossible."

I'd argue that the mathematical operations themselves are usually not that complicated. More importantly, the whole book seems to be about ways to derive the (probable) input of a hash function from the output. It is not literally impossible.

> "It is important to note, however, that hash functions are not truly random;"

As the author writes elsewhere, hash functions are deterministic and not random at all. Calling them not truly random seems to imply that they are somewhat random.

> "When encrypting a file or any kind of data with AES for example, the program leveraging AES will prompt you for a password. Yes, a password."

Yes, this is a book about password cracking, but there are lots of cases where programs use AES with a computer-generated key and won't prompt you for a password. E.g., TLS.

(Just to reiterate: I am not trying to diminish the author's work, I wanted to suggest ways for improvement. I might be wrong or overly pedantic.)

This book is currently not really relevant for me, so I just skimmed the samples on Amazon. I found the technical content to be reasonably accurate and interesting although sometimes a little bit verbose (e.g., the section about 'what is a password') or slightly imprecise. In general, I think this book might have benefited from a thorough copyediting pass. There are quite a few grammar errors and unpolished sentences in the book, e.g.:

> The reason why Linux is imperative is that well, for one, most of the tools we will use, while indeed have builds for other systems, like Windows, in this book we will work with Linux.

Wishing you success and keep on writing!

I originally assumed that the bulb would be somehow connected to voltmeter and amperemeter.

¹) I just found out that it is more commonly called 'ammeter' in English - which is so unintuitive that I prefere 'amperemeter'.