It begs the question, who is at faulty here??
I would never run a piece of software that either itself gets compromised or the tons of plugins it sometimes depends on.
171–180 of 368 posts
It begs the question, who is at faulty here??
I would never run a piece of software that either itself gets compromised or the tons of plugins it sometimes depends on.
Earlier quoted context omitted.
Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.
3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec. We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specifi…
"It resolved its C2 domain through an Ethereum smart contract, querying public blockchain RPC endpoints. Traditional domain takedowns would not work because the attacker could update the smart contract to point to a new domain at any time." Does this mean firewalls now have to block all Ethereum endpoints?
Earlier quoted context omitted.
For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond…
Is this a win for .NET where the mothership provides almost all what you need?
Earlier quoted context omitted.
> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assign…
I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”
We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready.
If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster-releasing in the long (and medium) run. You’d be shocked at how productive your developers are when they aren’t task-switching every thirty minutes to put out fires, or when feature work isn’t constantly burdened by having to upend unrelated parts of the code due to hopelessly interwoven design.
Earlier quoted context omitted.
I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”
“The alternative is that nothing will ever get released because devs will take forever making it perfect” is a really lame take. We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready. If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster -releasing in the long (and medium) run.…
Earlier quoted context omitted.
3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks t…
Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right?
So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea.
I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way."
So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
Earlier quoted context omitted.
3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
You assume that PMs will just accept whatever estimate you give and not just say 2 weeks from the off and refuse to budge.
Earlier quoted context omitted.
Assuming that the majority of repositories will be malware with SEO hooks, how would one locate a safe directory using only a search engine (as opposed to whispered tips from coworkers, etc)? I don’t see how proliferation of repositories improves things for users. (Certainly, it does serve up the usual freedom-from-regulation dreams on a silver platter, but that’s value-neutral from a usability perspective.)
The aggregators can choose who to index, and we operate one at fair.pm - the idea being that you only federate repositories that meet requirements, and can defederate those which are bad actors. (End users can install directly from repositories though, and can always switch the aggregator if they find the rules too restrictive - no lock-in.)