Well, I've asked ChatGPT with your prompt and came out with a very long comment. Asking to shorten it, we get:
"Figma is basically Google Docs for design — a fast, browser-based tool where multiple people can edit the same UI file in real time. No installs, no emailing files around.
Its magic as a business is the frictionless onboarding (just share a link), viral team adoption, and a freemium model that naturally expands into enterprise contracts. Works cross‑platform, so it spreads fast.
That combo — great product + viral growth + strong enterprise lock‑in — is why it became the design platform and why Adobe was ready to pay billions for it."
In the longer form it was also enthusiastic about the WASM part, but that didn't make the cut.
This is a horrifically bad take, I know you probably see it this way because you can't imagine how easy some of these mistakes are, however I can assure you that there are MANY TIMES that I've accidentally found issues with systems.
I do work in security, the average person would write this off as "oh just shitty software" and do nothing about it, however when one know what the error means and you know how the software works, errors are easy to turn into exploitable systems.
I once had a bank account that fucked up data validation because i had '; in the transfer description of 120 characters. Immediately abusable sql injection.
After my first time reporting this OBVIOUS flaw to a bank along with how it can be abused in both database modification and xss injection, I had to visit the local law enforcement with lawyers because they believe that 'hacking' had taken place.
I now report every vuln behind fake emails, on fake systems in non extradition countries accessed via proxy on vpn. Even then I have the legal system attempting to find my real name and location and threaten me with legal action.
Bad actors come from non extradition countries which wouldnt even TALK to you about the problem, You'd just have to accept you get hacked and that is the end of the situation.
Its people like yourself who can't see past the end of their nose to realise where the real threats are. You don't have "it straight".
I took it as a take on the face of the proposal: "hackers should have strong legal protections so long as they report any security vulnerabilities that they find."
As stated, it's ripe for abuse. Perhaps they could have been more charitable and assumed some additional implicit qualifiers. But defining those qualifiers is precisely the difficult part, perhaps intractably difficult.
In the US private investigators often require a license to work, but AFAIU that license doesn't actually exempt them from any substantive laws. Rather, it's more a mechanism to make it easier for authorities and citizens to excuse (outside the legal process) otherwise suspicious behavior.
Rather than give special protections to a certain class of people, why not define the crimes to not encompass normal investigative behaviors typical in the industry. In particular, return to stronger mens rea elements rather than creeping in the direction of strict liability. Adding technical carveouts could end up making for a harsher system; for example, failing to report in an acceptable manner (when, what, where, how?) might end up sealing the fate of an otherwise innocent tech-adept person poking around.
> Rather than give special protections to a certain class of people, why not define the crimes to not encompass normal investigative behaviors typical in the industry.
This would be an acceptable alternative, and may even be workable.
> failing to report in an acceptable manner (when, what, where, how?) might end
> up sealing the fate of an otherwise innocent tech-adept person poking around.
You've hit exactly the problem, I feel like you too might be working in this area. Not many people come to this kind of logical conclusion.
Companies will care about securing their systems and paying for these services if it costs them Real Money when they neglect to do so.
Until then, they'll continue to not care. The solution is not a legal framework presuming good samaritans will secure the networks and systems of the world.
I think that threading macros is different to method chaining (at least to my understanding), method chaining works on the object returned, and threading macros can work on raw data or objects.
> I haven't found this to be the case, they both require effort to clean.
Electrics are (generally) a smooth flat surface. Of course you're not getting out of it entirely, but it's still a question of night and day compared to the mess of a gas stove.
Electric stoves generally use raised exposed heating coils (that are rarely able to stay level, making oil and other liquids run to one side of the pan, making frying etc. stuff a headache). I've lived in one place over 40+ years that had a flat top electric stove, and it suffered from being even slower to heat up than regular electric.
I'd kill to have a gas stove and be able to do serious stovetop cooking.
Any modern (made within the last ~20 years) electric stove is going to just have a flat top with markings, just like an induction stove.[0] Before that you'd have a flat surface with a cast iron disk protruding for each hot surface.[1] Less trivial than the flat surface, but still not too bad. I've seen.. maybe.. one with an exposed coil in my entire life, and that thing was ancient. Faaaaar from "generally use".
The smell, worry about it being left on. I've got kids, they like to cook, I'm sure they'd be capable of dealing with a gas cooktop (we've got a bunsen burner for science stuff) but it's just nice not having that.
We don't get gas pipeline connections here, we get bottles that a company comes and replaces.
Compared to gas, I find induction just as responsive, more powerful on the highest setting. A nice feature is the auto heat which gives it more power until the pan is at the target level then reduces. I also think (but not sure) that the lowest level is far cooler than the lowest gas setting was, making it easier to use for baking - melting butter, chocolate, things that require gentle warming.
So, as I say, other than the specific flames around a wok, it's better overall. I do have an induction wok, it's not as good. It's fine though, I wouldn't trade or bother with a separate gas cooktop just for that.
Regarding kids + induction vs gas. I think it is much easier for kids to harm themselves in case of induction. They surely have learned that fire burns, thus they are conditioned to avoid touching fire, whereas induction is different. My two cents.
for what it's worth I switched from gas to induction, and to me it's a clear upgrade in almost all aspects. Induction is worse at spreading the heat, but other than that it's just... better.
When I am cooking, I often pick up whatever I am cooking in and I rely on the flames, so I prefer gas for this reason alone, because I cannot do the same with an induction. That said, I could get used to induction. I have used it for some time a long time ago.
>>I haven't found this to be the case, they both require effort to clean.
Unless you start cooking with dirty induction cooktop, they are much easier to clean simply because the temperature is much lower, the surface is flat and easy to clean
I don't know enough about guile, but janet was pretty easy to develop for .
Its binaries are quite small, could wrap and embed raylib and a few small c libraries with no hassle. This makes distribution much easier.
For my simple 2d game jaylib (raylib) code.
ls -laoh build/app
-rwxr-xr-x 1 worthless 2.8M 27 Jul 17:28 build/app
otool -L ./build/app
./build/app:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 706.41.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2674.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4034.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1951.0.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4034.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
I believe those are pretty standard to have on most OSX machines, the situation is similar for my Linux system.
The LLM's really can't deal with janet though, they seem to think its clojure and screw up a lot of things.
Feed your LLMs the documentation and example code (perhaps the whole stdlib if it fits). Tell your LLM that it is not Clojure nor Scheme, it is a different language. I have worked with more niche languages than Janet with Claude before this way, successfully.
reply