> "Founded in 2013, Bending Spoons reported a net income of $27.5 million on revenue of $601 million for the three months ended March 31, compared to a net loss of $112.2 million on revenue of $259 million a year earlier. A large chunk of its revenue comes from recurring subscriptions, providing a more predictable stream of income."
Clever, shitty numbers and they decide to IPO at the peak of the "actually SaaS is worthless" hype. I wish them the worst, considering their business model.
In Italy they are really frowned upon by developers. They add 0 value. And it's not like "Oh, VC firms add 0 value to companies they acquire", this is really messed up.
So roughly $100m/year profit(edit). They are looking for a 20Bn valuation but interest rates are at 5%? How does any of this make any sense? That or we are in a real bubble.
You're mixing up the numbers. Their annual run rate is $2.4 billion. Revenue grew 140% YoY. That's an 8x sales multiple on good growth. The valuation is not egregious.
Sorry I meant profit. On a 5% interest, you get 1bn (pure profit with no risks) per year for a 20bn of capital. Their revenue grew 140% YoY but does that account for new acquisitions? Also, their profit needs to grow x10 in order to match bonds. It may have made sense in a 0% interest rate world but not at 5.
It's a business model that's like a shark: perpetually swimming and eating or it's dying. That's how they can show big increases in revenue, but the profits are always decaying along with the products.
> " 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.)
> "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).
> The angle of attack, α, is the angle between the kite’s sail and the incoming wind. As α increases from zero, C_L increases approximately linearly until a critical angle (typically 12–18 degrees for flat surfaces), beyond which the airflow separates from the upper surface and the kite stalls (DT Online, 2024).
The supporting reference is [2]; this doesn't refer to a linear releationship or a critical angle, but does say that the angle of attack is typically 20 to 30 degrees (contradicting the claim that a kite would stall if the angle is above 12-18 degrees).
So I agree that this website does not seem trustworthy. Specific claims may or may not be correct, but they're not supported by the presented references.
A smart approach that does not solve the AI problem - actually flipped classrooms work worse now due to AI usage.
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.
Research has shown that testing is far and away the most valuable academic tool.
Just have a quiz every day. In fact, have _TWO_ quizzes, one at the start of class and one at the end, and take the higher of the two scores. In between the first quiz and the second, work through problems with the students designed to help people that bombed the first test figure out how to pass the second.
The best part of a quiz everyday is that in addition to the testing effect, you can easily fit in the spacing effect and interleaving effect. It’s a rock solid combo, that is well studied. We have pretty strong evidence that it works for all students in all domains.
I actually like this idea - makes sense at face value - as long as they design the test in such a way that it aptly applies the knowledge instead of just learning for the sake of passing test like questions...
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.
reply