moring

> Even revealing enough details, but not everything, about the flaw to convince a potential buyer would be detrimental to the seller, as the level of details required to convince would likely massively simplify the work of the buyer should they decide to try and find the flaw themselves instead of buying.

Is conning a seller really worth it for a potential buyer? Details will help an expert find the flaw, but it still takes lots of work, and there is the risk of not finding it (and the seller will be careful next time).

> And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.

They also have the money to just buy an exploit.

> The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.

I'd imagine the skills needed to get paid from ransomware victims without getting caught to be very different from the skills needed to find a vulnerability.

Using whatever platform you prefer with a subset of people is fine and doable, but you're lying to yourself if you think that it is the "start" of anything.

The "pairing" probably makes sense if you deep-dive into the technical details. My guess is that the battery has software on it to improve performance, total life, whatever.

The real problem is that the whole is not designed to be user-servicable.

> The only system failure was not canceling their license beforehand.

Why was their license not canceled beforehand?

Did they not get caught? If so, why? Likely other drivers have noticed the bad driving behavior. If so, why did they not report it? If they did report it, did the reports get ignored? Is there even a system and process in place for such reporting?

If they got caught, was there hesitation to revoke their license? If so, why? A potential factor would be driving in an area where you have to drive to get anywhere, which is common in the US. Why has it not been addressed that you have to drive, even if your driving habits are bad?

If bad driving behavior is too hard to punish, why? If regulations do not allow adequate punishment of bad driving behavior, why have these regulations not been changed? If evidence is missing, what evidence would that be, and how could it be collected?

If the driver was drunk, what would have been the alternative to driving? Is there adequate public transportation for drunks to get home? "adequate" depends on the drinking culture in the area where that happened.

If the driver was untrained, why were they allowed to drive? You wrote about canceling their license, so they did get a license. How was that possible without training? Does the process for handing out licenses have to be changed? Is frequent re-training necessary (more data is needed for that; if that data isn't avilable, why not?)

Obligatory link to the CAST handbook in case you want to follow that line of thinking: http://sunnyday.mit.edu/CAST-Handbook.pdf

That was my first thought. A page that talks about cognitive load waits for you to start reading, then throws a newsletter sign-up dialog in your face? The irony...

Oh, but it gets better:

> We have been sold a lie that icons are the universal language of the modern interface.

... placed directly below a button bar that contains only icons.

Did you mean arrays instead of lists? Arrays behave as you describe (with ArrayStoreException when you write a wrong value to an array). List<> is invariant WRT its type parameter.

The book "How Big Things Get Done" by Bent Flyvbjerg nicely answers all the concerns mentioned in this thread. I'll answer here to avoid littering replies everywhere.

> But I do still think there's a lot of value into coming up with a good plan before jumping in.

Definitely, with emphasis on a _good_ plan. Most "plans" are bad and don't deserve that name.

> be specified up-front, planned on JIRA

Making a plan up-front is a good approach. A specification should be part of that plan. One should be ready to adapt it when needed during execution, but one should also strive to make the spec good enough to avoid changing.

HOWEVER, the "up-front specification" you mentioned was likely written _before_ making a plan, which is a bad approach. It was probably written as part of something that was called "planning" and has nothing to do with actual planning. In that case, the spec is pure fiction.

> estimates provided

Unless this project is exceptional, the estimates are probably fiction too.

> and Gantt charts setup

Gantt charts are a model, not a plan. Modeling is good; it gives you insight into the project. But a model should not be confused with a plan. It is just one tiny fragment you need to build a plan, and Gantt charts are just one of many many many types of models needed to build a plan.

> before they even sign the contract for the next milestone

That's a good thing. Signing a contract is an irreversible decision. The only contract that should be signed before planning is done is the contract that employs the planners.

> Anyone who claims upfront specs are the solution

See bove. A rigid upfront spec is usually not a plan, but pure fiction.

> My approach, especially for a project with a lot of unknowns, is usually to jump in right away and try to build a prototype.

Whether this is called planning or "jumping in" is a difference in terminology, not in the approach. The relevant clue is that you are experimenting with the problem to understand it, but you are NOT making irreversible decisions. By the terminology used in that book, you are _planning_, not _executing_.

> after the 2000 pages specification document was written, and passed down from the architects to the devs

If the 2000 page spec has never been passed to the devs while writing it, it's not part of a plan, it's pure fiction. Trying to develop software against that spec is part of planning.

Devil's advocate here (not associated with Duolingo, and in fact I haven't even used it):

> They reset your cleared lessons and require you to redo them if they add new vocab to them

The same would be true if that case was never considered, or postponed, during development.

I tinkered with my own toy learning platform; I too found the question of how to deal with added content to an already-completed lesson, and the answer is that there is no easy answer. Every solution sucks in a way.

> as well as randomly clearing them in the name of making you practice them again

Anki does the same, calls it "spaced repetition" and says it's a feature. Should we ban Anki now?

I don't think graphics devs changing over would change much. They would probably not lament over 16ms, but they would quickly learn that performance does not matter much in application development, and start building their own abstraction layer cake.

It's not even that performance is unimportant in absolute terms, but rather that the general state of software is so abysmal that performance is the least of your problems as a user, so you're not going to get excited over it.

(1) disguise as an LLM to have them give better problem descriptions to you (2) provide an LLM for your users that lets you read their chat to understand their problem

and:

(3) try to understand why they are communicating differently to an LLM. Immediate replies? Different feelings knowing they don't talk to a human? Genuinely better help? Not getting treated as stupid?

All or none of these may be true, but if it's consistent behaviour then there is a reason for it.

He doesn't give the chairman due credit, IMHO. The chairman collected information to help solve the problem AND it actually was the information needed. Without it, the author might look for "randomly unreachable servers" for a long time.

It's almost raw data -- exactly what you would wish for. By lecturing people that "email does not work that way", next time you either get no data at all because people don't even try, or no data because people hide it thinking email doesn't work that way, or a misguided conclusion when a layman tries to make a better guess at the cause of the problem.

This is the right point to mention "How Big Things Get Done" by Bent Flyvbjerg. You can iterate your design without putting lives into danger.

"I spent weeks planning" -- using the terminology from that book: No, you didn't spend weeks planning, you spent weeks building something that you _thought_ was a plan. An actual plan would give you the information you got from actually shipping the thing, and in software in particular "a model" and "the thing" look very similar, but for buildings and bridges they are very different.

"Just an AI that has fired everyone"

At least it did not turn against them physically... "get comfortable while I warm up the neurotoxin emitters"

Both the article and many comments here seem to miss that UPDATE deletes data -- the previous value of the field being updated -- which is a serious problem if soft-delete is your tool to keep old data. If you actually want historical data, you'll need logs or go straight to event sourcing.

Is that NSW = New South Wales? I'm asking because Wikipedia lists New South Wales as a population of only 8.5 million, and those crime numbers are insanely huge relative to that.

> why don't OSS maintainers just charge for their work?

What if we turn this from a rhetorical question to an actual question?

My totally unverified take:

1. Missing transaction / Payment infrastructure. The same reason why paid music streaming services were successful depite piracy being a thing.

2. Bureaucracy associated with earning money. In many countries, going from "unpaid" to "€1 per month" is a nightmare.

... and a suggestion to make both less dire: A transaction infrastructure that allows small projects (that wouldn't be a cash cow anyway) to forward all payments to another project of the project Author's choice.

Edit: See https://old.reddit.com/r/linux/comments/d2ic2e/krita_is_now_...

I did not expect how bad this was handled in the article:

> It’s easy to forget how simple a website can be. > ... > If you don’t have a domain or hosting yet, now’s the time to buckle down and do that. Unfortunately, I don’t have good advice for you here. Just know that it’s going to be stupid and tedious and bad and unfun. That’s just the way this is.

Yup, it blatantly left out the hard part, and at the same time contradicted the initial claim almost literally.

Kinda reminds me of reading a dozen articles that went, "Learning how to typeset a document with LaTeX. This article assumes that you have LaTeX installed already." ages ago.

Kinda makes me wonder: If the point isn't to show how to make a website, or typeset a LaTeX document.... what IS the point?

Thanks for your reply. This seems like it builds the UI almost completely in server code, which I usually avoid these days because in my experience, it causes other problems. I should have mentioned that in my question.

> By the way, without React shouldn't default to jQuery

I never claimed it does. I stated my experience to give context for my question for other solutions than React.

> The problem is simple: its where people stake their career

I meant my question to be about building a large frontend without a large framework, purely in technical terms. This has nothing to do with career choices.

Non-constructive reply: Developers have been burned too many times by snake oil vendors and "solutions" that only work for toy examples. Also, I've never seen being slow to be encouraged anywhere. Most consider it an acceptable tradeoff though.

Constructive reply: What would be an approach to writing a large web frontend (large as in, many pages and controls) without using a large framework?

I'm asking this because I know how to do it in React but also how to do it "the old jQuery way" (or equivalently, using today's standardized builtins). Productivity is easily 100x larger with React.

edit: Ideally, together with a link to an example open-source application that does it that way, to understand how it works and feels at (code) scale.

Yes. A number like

123456 = 1 * 100000 + 2 * 10000 + 3 * 1000 + 4 * 100 + 5 * 10 + 6 = 1 * (99999+1) + 2 * (9999+1) + 3 * (999+1) + 4 * (99+1) + 5 * (9+1) + 6

When checking whether it is a multiple of some k, you can add/subtract multiples of k without changing the result, and those 99...9 are multiples of both 3 and 9.

So 123456 is a multiple of 3 (or 9) iff

1 * 1 + 2 * 1 + 3 * 1 + 4 * 1 + 5 * 1 + 6 * 1 = 1 + 2 + 3 + 4 + 5 + 6

is. Apply the same rule as often as you want -- that is, until you only have one digit left, because then it won't get simpler anymore.

I don't think that games, art and the demoscene can be used as evidence here. Implementing something like C# means you have a spec to implement. You have to be creative with the implementation without violating that spec.

All the three of games/art/demoscene on something like the C64 have a rough idea as the spec, but then you'll get creative about how much of that "spec" you can bend and violate to meet the technical limitations of the C64, while still being fun.

Spore (C64) also had that and was even a year earlier than Slimey's Mine. So even multiple instances of prior art are not a blocker towards getting a patent...

How did you come to the conclusion that those have not been peer-reviewed? Every uni course that presents the work of these people implicitly reviews it for consistency, and the advanced practices courses repeat their experiments.

Also, survivorship bias.

I'm sceptical about fixing (in the sense of a lasting solution), but it might be a very powerful tool to communicate to devs what the UI should look like.

It would sound more logical to me to buy a stack of pre-made patterns (e.g. coin or cube form-factor) and glue them into a like-shaped slot in a 3d-printed playing piece. Assuming that is possible, and you'd still have to make a conductive path to the person touching the piece, but this would be much easier than printing the pattern yourself.

I'll soon get to make technology choices for a project (context: we need an MQTT broker) and Kafka is one of the options, but I have zero experience with it. Aside from the obivous red flag that is using something for the first time in a real project, what is it that you dislike about Kafka?

That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly):

(a || b) && c --> a || b && c

which then gets interpreted as

a || (b && c)

I feel like this is the time to mention "How Big Things Get Done", by Bent Flyvbjerg. "Long planning vs. start prototyping" is a false dichotomy. Prototyping IS planning.

Put another way, refining tickets for weeks isn't the problem; the problem is when you do this without prototyping, chances are you aren't actually refining the tickets.

Planning stops when you take steps that cannot be reverted, and there IS value in delaying those steps as much as possible, because your project then becomes vulnerable to outside risk. Long planning is valuable because of this; it's just that many who advocate for long planning would just take a long time and not actually use that time for planning.

Or, if you don't want to fight this battle in lieu of other tenants, _threaten_ to sue to either force the agency to reveal the name and address of the landlord, or ideally, have them put pressure on the landlord to return the security deposit.