Its the now-classic "Sorry I drowned little Timothy. Here is a breakdown of what happened" followed by "Let me try to respawn little Timothy on a new map"
That’s the workflow feature I badly want: for it to create a side list of things like that. Currently it either accumulates slop or goes on side quests far too easily.
This might be as easy as a directive to populate a .md file.
Exactly. We have about 6 new repos for new green-field projects each with 700+ auto-generated issues so far. No one is looking at them, but we do have them tracked so "Mission Accomplished" GWB-style.
> This might be as easy as a directive to populate a .md file.
It probably is. But do you really think anyone is gonna bother with the multiple daily (or hourly for green field projects) `+8,234/-3,734` PRs everyone is submitting?
The joke I was referring to is the common
// ksmith (3/23/1997): This is a temporary hack for now. Find a better way to do this asap.
I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it.
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
That’s the mental model that works for people, specifically those that come from VM workflow.
Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective.
Virtualisation has advanced greatly since docker was introduced, if your running in local hardware that’s supports virtualisation, Docker should be running images fully virtualised. There is no good reason to use the OS kernel for most use cases as the performance impact is negligible. If you need kernel access there are better options, like systemd containers.
I agree that virtualization has seen great advances. Kata containers on k8s are almost (not quite 100%) drop in replacement. Regardless those last 10% remain a problem.
I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back.
Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points.
Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs
> Kotlin <-> Java interop is a totally optional topic you could have skipped over
This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?
Of course they are not complex. They do have a network effect though. If you go to your local ISP and say “hey, my 500mbps plan is only doing 100mbps on Speedtest.net”, they’ll “fix it” (usually by working with Ookla to put an edge endpoint on their network)
If you tell the “hey frankyspeeddetect.com isn’t doing my 500mbps” they’ll tell you to it’s an issue with that random website. ISPs and services reach out to Ookla to onboard with them because they have a network effect/mindshare of whatever you wanna call it
When I used a major cable ISP, often my connection seemed slow, so I'd go to speedtest.com. The speedtest would be fine... and then I would magically have faster network performance again.
It happened enough times that I'm suspicious the ISP had some way to detect if you run a speedtest, and then prioritized traffic to that customer.
This was one of the reasons given, at the time, for why Netflix created fast.com. It's served by the same infra that does their streaming, and is thus difficult for isps to game. That is, it'd be hard for them to do some hack to make fast.com numbers without also benefiting Netflix streaming performance in the bargain.
Actually I thought Netflix had already acquired Ookla / speedtest.com, so I was surprised to see this headline. But it looks like this was just the Mandela effect.
That said, why didn't Netflix acquire the market leader in this space? Creating their own seems way less useful, since network effects are the whole point.
Based on Accenture acquiring them, I’d guess the actual business wasn’t really interesting to Netflix. And that leaves the infrastructure, where the value they get is it being Netflix infrastructure. I can see why they spent the money on a really good brandable domain instead.
Because Netflix doesn't care what your connection to speedtest.net is, they care what your connection to your closest Netflix server box is. A while back, Comcast/your last-mile ISP was throttling traffic to Netflix to get Netflix to pay them. So while Netflix's box had plenty of bandwidth to their ISP, your ISP wasn't using it, intentionally. Fast.com was their response to that, so you could blame your ISP and not Netflix for being slow.
That’s a really over simplification of the issue. Plenty of Netflix edge CDNs are (and always were) ISP hosted. It’s a win-win for both and a complete no-brainer. The ISP v. Netflix argument was always about contract and margin negotiations. Flat rate, usage percentages, minimums, maximums, special plans, cuts, etc. who has the upper hand in the negotiation so to speak. Funnily enough the repeal of net neutrality gave those smaller ISPs much better position in the negotiation with big tech, not necessarily Comcast. The internet discord focused on Comcast and Verizon because fuck those guys. Who is gonna argue in favor of Comcast or Verizon? But the real winners were thousands of smaller regional ISPs.
The internet discourse focused on the big ISPs which refused to deploy CDN nodes and then said they needed to double-charge for peering capacity. Most smaller ISPs deployed those Open Connect nodes either becsuse they weren’t as greedy or felt that their customers had alternatives.
> It happened enough times that I'm suspicious the ISP had some way to detect if you run a speedtest, and then prioritized traffic to that customer.
ISPs definitely know when you run a speedtest.net test. 90% of the time, the data for that comes from boxes/services they host themselves. It’s not exactly hidden either. It’s a typical program any ISP can sign up for and you can easily see the destination the test is running against. I won’t be surprised if some have some logic to prioritize particular subscribers plan once they have detected a test from them. They probably view it as a “customer support calls reduction” feature.
>When I used a major cable ISP, often my connection seemed slow, so I'd go to speedtest.com. The speedtest would be fine... and then I would magically have faster network performance again.
Yeah, I suspect you could script it to do it daily. They definitely seem to deprioritize traffic from people that don't complain.
All these numbers are fake. They are all special cased in most ISPs with the cooperation of cloudflare, Netflix, OOkla, Akamai, Google, etc. The centralization of the internet around AWS, Azure, Google, Netflix, Cloudflare, etc has been a godsend to ISPs and the internet infrastructure in general. Maintaining good network conditions to 4 or 5 dozen networks and working with them closely is so so much easier than maintaining full peer-to-peer network conditions. Go ahead and try to test internet speed to your home network over a wireguard VPN and compare it to the performance of the same VPN when connecting to any of the major services. Try to setup a tunnel between your house and your friends house in the same city and test the speed and compare it to fast.com or cloudflare.com or speedtest.net
I had not heard of http://speed.cloudflare.com either. I just tried it and I did not get accurate numbers. wifiman.com, from Ubiquiti/Unifi team does provide more accurate numbers. fast.com numbers are pretty accurate as well.
I'm a huge fan of https://speed.cloudflare.com/ and you'll have to come with better evidence. Also fast.com doesn't even give upload speed and latency.
That's why speedtest.net is a great purchase for Accenture. Of course Cloudflare's speed test is accurate: it's a test of how fast your connection is to their network. No more, no less. That their network doesn't have the same PoPs means it'll have different numbers than Ookla's test, your ISPs advertised numbers, Netflix's test, and any other speed test. But for people that don't see the Internet as a pile of different interconnected networks, the conclusion that a particular test is inaccurate is a win for Accenture.
Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
If the random blob is running inside of a real sandbox (Landlock/Bubblewrap, VM, ...Docker) then I would take the blob, because I can reason about its capabilities without inspecting its internals. The LLM can run curl as much as it wants if I've `unshare()`d its network access. MCP is an instant obligatory sandbox escape unless I also manage to deploy all the MCP servers inside the sandbox.
And yes, sorry, I was talking about local MCP. I should have made that clear. I do see people using local MCP quite a bit (Ghidra MCP, Playwright MCP, etc), but maybe this is more of a hobbyist thing.
Because you don't agree doesn't make the legitimate callout (i.e., victim-blaming “what were you wearing” vs. calling someone “unhinged” after they've endured repeated abuse/stress) a logical fallacy. Rather it positions you in opposition.
I don't really see any evidence of abuse in this post, though. It doesn't really say what Microsoft did, other than ban them from github after they said they will "make Microsoft's bones shatter".
It reads to me like Microsoft didn't pay him what he thought he earned from the exploits (i have no idea who is in the right on that), and then he published a zero day with no notification and threatened the company. Doesn't seem ridiculous to ban them at that point.
Again, I don't know the details so I cant say who is in the right, but the researcher comes off as a little bit unhinged and entitled. Not paying a bug bounty is 'ruining my life'?
> Again, I don't know the details so I cant say who is in the right
You are unsure of the details, so you instinctively choose to align with the $3T corporation. Further you assert the responsible discloser is "unhinged" for having a reaction to sustained abusive behavior by that $3T corporation.
Who exactly is unhinged here: the person who had a human reaction to abuse, or the person who thinks they are social in-group status with Microsoft? My vote is on the latter.
I'm 90% those features were among the top issues on github/github repo back when it used to be there. The joke was always about how barebones github issues were was a common thing troughout the 2010s. Once they added that whole "Projects" thing, the joke became how complicated it is.
Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to you, you blackbox everything but the surface areas you need to touch. It's why there are 14 implementations of a background service 8 dependencies that do the same thing, 6 overlapping frameworks, a complete mismatch in style, approaches, etc. It doesn't really matter.
It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.
yes, of course. I meant "it doesn't really matter" in the sense that businesses have been dealing with this since the beginning of software. Strong ownership and passion was one of the selling points of OSS, but that style of ownership was always very very rare in corporate. It just doesn't really fit with how businesses operate. The "passion" is ARR, not engineering principals. Most software is built, sold, and bought by people who don't use it directly.
> The code base itself has never and will never matter in the big picture
Clearing my throat: I am the first person to tell everyone on the team (repeatedly, until they are sick of hearing it) that the users, use cases, and organizational objectives are always more important than the technology.
But, in "the big picture" - the Linux codebase doesn't matter? The codebase that powers AWS doesn't matter? Hell, the Microsoft Office codebase doesn't matter? Look at what's happening to Windows when they treat it like the codebase doesn't matter.
For a tech org, the codebase is the reification of all of your objectives, all of your knowledge about your users and use cases and processes. Long term, a mature codebase plus people who understand it is one of the most valuable things you have. When orgs don't realize this, when they treat their workers and their work product as disposable commodities, we call this "enshittification."
Even a bad developer, that is, the average developer, develops a whole in which the parts have some degree of coherence. AIs simulate that, but they don’t have intent and thus this coherence is broken in large code bases.
reply