Never heard of Flux.ai before. It seems to be a 3D circuit designer with 'AI'.
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.
> 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.
Their PCB designs are mostly CC Attribution-ShareAlike typically.
What's funny is that most Adafruit products aren't exactly secret. Most of them have open source schematics and PCB layouts. Even when they aren't, they pretty much just a reference design from a data sheet. The kind of people that have the competence to be using board design software could replicate their designs pretty easily.
I think the parent commenter agrees with you: because there is tight quality assurance and - in many countries - a license needed to practice medicine, the interviewer can just trust the system instead of having to evaluate the competence of the applicant through questions and coding assignments.
(I'm not sure whether I agree with the commentator that a SE license would be that helpful in practice.)
Thanks for sharing. This looks interesting. Impressive achievement.
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.
Yea after skimming the samples on Amazon I noticed that nearly every single sentence had at least one comma in it (adding zero value). It feels like I'm reading someones thoughts.
Personally, I love abusing commas for comments and shitposting, but they should be avoided in informative resources like books, otherwise, it looks like a word salad. Say your thoughts and ideas with boldness and certainty.
But hey you write better than I did at 18, so I ain't judging. Just trying to provide helpful feedback for you (the op) to improve on.
A few small things. You might call this nitpicking. And, as I wrote, I found the technical details generally accurate.
> "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.)
> 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.
I think you're not being pedantic enough here. "Probable" is doing some heavy lifting. And the phrasing is "derive the input," which I think is fair to say. The best you can do with a proper hash is discover one or more possible inputs, but you're not deriving them from the output; the output is just used to check the result. The many-to-one nature of a hash precludes determining the exact input.
Fair point. I was initially thinking about rainbow tables. Taking a hash and looking up associated passwords in a table feels like deriving to me - but I'm not a native speaker so I might have a wrong feeling here.
(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.)
To me, "deriving from x" means performing a mathematical function operating on input x. By my own definition, I suppose a rainbow table lookup is a derivation, but I wouldn't consider actually computing the table to be one. Hash-cracking is more like guess-and-check than mathematical decoding; the hash to be cracked is just a verifier and not an input, which is why I make the (admittedly pedantic) distinction.
> (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.)
I think it's a canonical way to generalize the audience as in "99 percent of the time when cracking passwords, one will be staring at a black terminal filled with white text" just as in the German "man". So with that in mind maybe you no longer have a reason to be offended :)
I absolutely agree. There were no other comments on this post when I wrote my comment. Thus, I wanted to encourage the author and provide some constructive feedback in case nobody else would reply.
Thanks for the feedback. I did my best with grammar. Unfortunately, English is not my native language. I'll definitely keep grammar corrections in mind for future revisions!
I think I don't completely understand your idea. The current flowing through the amperemeter¹ depends on the voltage and the resistance of the incandescent(?) lamp. To vary current by the minute, you would need a digital resistor or potentiometer, I guess. Is that your suggestion?
¹) I just found out that it is more commonly called 'ammeter' in English - which is so unintuitive that I prefere 'amperemeter'.
If you have a feedback loop I'm sure you can still do it with an either implicitly or explicitly filtered PWM. Remember we're talking averages not instantaneous, so the average current through the bulb should be proportional to the average voltage across it, though the resistance will change as the bulb heats hence the feedback. You could also do this with a buck/boost regulator and current sense resistor plus op amps to create a constant current supply.
"average current through the bulb should be proportional to the average voltage across it" That is exactly correct, the reason they were seeking clarification, and the core of suggested solution.
V=I*R
If V = Hours and I = Minutes, then by necessity R=Hours/Minutes. Typically a light bulb has mostly fixed resistance (R). Adding a potentiometer to the circuit allows you control the value of R.
So lightbulbs actually dont have fixed resistance. The tempco is pretty big, and temperature of course depends on power (with an annoyingly large time lag when power is reduced).
That being said, the bulb does have a well-defined resistance at a given point in time, so voltage and current are of course not quantities that can be indefinitely controlled.
This falls into the same category as “why isn’t my power supply with voltage and current controls working correctly?!?”
Oh - it didn't occur to me that the original poster might have thought about three different circuits - one with a voltmeter, one with an amperemeter, and one driving the light bulb. Maybe that was their intention.
I originally assumed that the bulb would be somehow connected to voltmeter and amperemeter.
Interesting and well written article that mirrors/foreshadows how LLMs do and will change other scenes.
As I don't know much about the CTF scene, I looked for other takes on this topic.
Here's an article from 2015 about how tool-assistance already changed CTFs:
> Individual skill will undoubtedly be a factor next year. But, I'm left wondering whether next year's DEFCON CTF will tell us anything more than how well-developed each team's tools are (and how well they can interpret the results).
And here's someone explaining how Claude Max allowed them to win CTFs:
> I had always been interested in CTF as one of the only ways people could compete and show off their skill in coding/problem solving on a global scale. It was just too difficult and didn't make sense for me to learn the fundamentals as an electrical engineer. As time went on, I got better and better, and it was hard to tell whether it was because of experience or if it was because of improvements in AI.
> I accomplished my goals, and for that reason I'm quitting CTF, at least for now. [...] I'd like to think I highlighted the problem before it became a bigger issue. So, how do we fix this? Teams and challenge authors losing motivation is not good. CTF dying is not good. AI bad. Or is it?
The only article that saw LLMs as a non-negative force for CTFs was this one. Fittingly, it sounds like LLM output ("Let's be honest", "This is where things get interesting.") and only contains hallucinated references.
Funny. At my son's school in Germany, students may bring any device they want without central administration (just Wifi and web platforms). It works quite well without inundating IT staff with support requests.
(To achieve at least some similarity of systems, you get a partial refund if you buy either iPads or convertible notebooks running Windows. My son's notebook technically runs Windows but he mostly uses plain Debian Linux with Xournal++.)
Actually, most videos seem to be real, run-of-the-mill showcases of various actuators the company sells. However, the owner seems to have added quite stupid AI-generated preview images lately.
I believe that bad/wrong explanations are actually much worse than no explanations.
Many figures seem to be either missing key information (e.g. Fig. 5: the elliptical deformation is not shown - a human artist would have created a very different figure to explain the concept) or plain wrong (Fig. 6: the threaded rollers have the wrong orientation, Fig. 7: the ball is much too large for the bearing and the whole figure seems nonsensical at first glance).
And if the author did not spot these obvious problems with the figures, they either have no clue, accept sloppy work, or didn't even read the article they generated. That article is not really good advertising for the company's products.
(That the link behind the author's name leads to their Wikipedia article which seems to be a revised copy of the CV on their website is interesting, too.)
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
reply