Hacker Newsnew | past | comments | ask | show | jobs | submit | InitialLastName's commentslogin

I don't know what of this is the prompt and what was the output, but that's a pretty bad schematic (for both aesthetic and circuit-design reasons).

The prompts were doing the design, reference voltage, hysteresis, output stage, all the maths and then the SVG is from asking the model to take all that and the current BOM to make an SVG schematic of it. In the past models would just output totally incoherent messes of lines and shapes.

I did a larger circuit too that this is part of, but it's not really for sharing online.


Yes but you concede it is a schematic.

How far we have come!

What am I missing? Spain is still a monarchy [0].

[0] https://en.wikipedia.org/wiki/Felipe_VI


Presumedly they meant when Spain was an absolute monarchy, instead of a constitutional monarch

My bad

It's worth noting that their argument isn't "Mark Zuckerberg perjured himself and needs to be jailed for it" because he said something strictly and knowingly false. It's "we shouldn't trust Mark Zuckerberg's testimony because he (and Meta more widely) have a long (long, long) history of being knowingly deceptive about the harms of their product".

If they had said that instead of "lied to congress" they would have lost less credibility with this reader. But then they wouldn't have gotten the click.

The word "lied" has a lot of layers[0] other than "knowingly said an outright falsehood". He may not have told an outright, provable falsehood (although some of these examples are close). He certainly has a long history of statements to Congress that are baldly misleading or belied by Meta's own internal records.

[0] https://en.wikipedia.org/wiki/Lie#Types_and_associated_terms


My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.

I came across a "special character" requirement while creating an account. The client validation was not the same as the server validation. The client proceeded as if my account was created, but it never was. The client functioned without an account until it was closed. I asked the creator what their app's problem was, why did I need to keep resetting my password, then be told that I don't have an account, and have to create it anew.

They would not believe I was creating an account and using the device, because their own logging was so terrible.

I had to send them a screen recording from me using this abomination, and only then was I told "you're using the wrong special characters". They helpfully gave me some examples of allowed special characters, which then would pass the server validation.

I wish they would have gotten rid of the account requirement, as the device and client software seemed to work fine without them.


Sometimes when that happens, and any of `:({ |&;` are on the no-no list, I try bypassing the client validations and setting my password to a shell fork bomb. So far as I'm aware it hasn't broken anything yet, but I'm determined to keep trying.

Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?

Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.

Sorry I'm a bit lost here. Are you saying requiring a special character and a number are dumb password policies? Wouldn't charset AND length make for exponentially higher entropy? 52 (or 62 for digits) to the length power vs (62+20 special chars) to the length power? Or am I missing something?

I guess what they're saying is that, for example, a password of length 12 has about 71 bits of entropy if using an alphabet of 62 characters, and 76 bits with an alphabet of 82 characters. But if you only increase the length by 1 you already get 77 bits with 62 characters only. So length beats adding special chars in that sense.

Gotcha, I guess my question is, why not both? Is it the requirement of special chars over a min-length password that is in question here? Like the system is like "minimum 8 char password but also three special chars, ancient heiroglyphs, and the blood of your firstborn child" when you can omit the special chars and just have min 16 char password for the same security benefit?

Not very meaningful to create yourself a problem to heroically overcome it later. You can already create enough problems unintentionally.

I don't quite follow your reasoning. All bugs are (usually) unintentional and created by the programmer.

By not using special chars in the first place, you can be sure you will not be able to run into any (unintentional) bugs later.

And not using special chars is cheap, as by requiring a min-length of 13 instead of 12, you can get an even greater level of security.


Got it, thanks! That makes sense.

Often, the same ones with limited punctuation also have length limits, so maximizing the character options is the only way to maximize entropy.

This is true, but I think the argument is that for maintainers of the system, it's more work to allow more char options when it (should be) more trivial to change MAX_PASS_LENGTH from 12 to 32. Like, if you're gonna add more restrictions, make it the ones that encourage, not block, more secure passwords.

A lot of the restricted stuff is cargo-cult fear of symbols that could be used in SQL-injection or XSS attacks.

A properly-coded system wouldn't care, but the people who write the rules have read old OWASP documents and in there they saw these symbols were somehow involved in big scary hacks that they didn't understand. So it's easier to ban them.


> But regardless of power, what the NYC mayor does is widely reported and it's often a political stepping stone (if not always successful) to something greater.

The only "greater" things any recent NYC mayors have done are bankrolling presidential campaigns and failed coup attempts.

Looking back at it, the last NYC mayor who held a notable political position after their mayoral term was Robert Wagner.


In fact, the last mayor I can find who served in a superior political office after their mayoralty was John T Hoffman, who was mayor from 1866-1868 and then NY Governor from 1869-1872.

Many of the software developers whose end users are their revenue source return to calling them customers.

This is the "LLM as junior engineer (/support representative/whatever)" strategy. If you wouldn't equip a junior engineer to delete your entire user database, or a support representative to offer "100% off everything" discounts, you shouldn't equip the LLM to do it.

Anthropic seems to be chasing that angle (c.f. their run of "AI that doesn't advertise to you" commercials).

Come back in 2-3 years. I bet will be one of the worst if still around

They have contracts with Palantir.

GP's question was about perception, not reality.

Virtually none of the Bible was written in a currently-dead language. Only small bits were written in Aramaic, and Koine Greek and Biblical Hebrew are pretty much comprehensible to modern Greek and Hebrew speakers.

Even the Christian era of the Bible being distributed in Latin made perfect sense since it was originally mostly being distributed to people who spoke Latin with questionable accents (and where Latin was the language everyone who was literate was literate in).


> Gaming HW is going to suck for many years.

Not just gaming hardware, everything where the electronics are a predominant part of the unit cost (read: all gadgets) is going to be seeing a big crunch in the next ~2 years (optimistically).

Approximately 100% of RAM manufacturing capacity on Earth has been reallocated to feed the slop machines; anything consumers get is effectively a production cast-off.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: