← Back to context

Comment by bcrosby95

12 hours ago

The way I usually prevent having to scale out to a bazillion systems is never getting more than 10 users.

18 comments

bcrosby95

Reply
steve_adams_86  11 hours ago

I wonder why Cloudflare didn’t think of this

  • kevin_thibedeau  11 hours ago

    This is Broadcom's business model

    • gerdesj  9 hours ago

      Quite. I was a VMware fanboi (25+ years, man and boy)

      I still look after a few VMware estates and a lot of Proxmox ones (that used to run VMware).

      Hilariously, VMware is described as "enterprise class", which I can only conclude means MVP and a bit wanky.

      Today I repaired a Proxmox HA + Ceph node using boring old normal Linux skills and as it turns out I have 30 years of those. Part way through a remote v8 to 9 upgrade I think I lost comms due to using OpenvSwitch for networking and despite using tmux for the upgrade session. Anyway, the Proxmox ISO was useless for rescue but the classic systemrescuecd worked nicely and I could run dpkg in a chroot.

      VMware "used" Linux and never really gave back. I don't miss fixing vCentres and all the other nonsense that "Enterprise" wankery has foisted on me over the years.

      9 replies →

forgot-my-pw  11 hours ago

The art of premature optimizations

  • smolder  3 hours ago

    The art is in knowing how to write software that doesn't perform like shit without doing all the work of measuring and refining. If you can save $100k in hardware costs in a couple days by just knowing what you're doing, that optimization is not premature.

  • jodrellblank  1 hour ago

    And yet when Prof. Donald Knuth wrote that in 1974 paper[1] it was in this context:

    > "The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal"

    also:

    > "In the late 1960's we witnessed a "software crisis", which many people thought was paradoxical because programming was supposed to be so easy. As a result of the crisis, people are now beginning to renounce every feature of programming that can be considered guilty by virtue of its association with difficulties. Not only go to statements are being questioned; we also hear complaints about floating-point calculations, global variables, semaphores, pointer variables, and even assignment statements. Soon we might be restricted to only a dozen or so programs that are sufficiently simple to be allowable"

    In a recent comment I mentioned a youtube interview with Rico Mariani, a performance engineer from Microsoft, and he said that he often got called into projects approaching their deadlines and not meeting their performance goals.

    In one anecdote he spent a couple of hours with a team and showed how their design could never meat the goal even with the fastest disks, CPUs, memory, and network. And commented how strange it is if they had spent a day at the start of the project whiteboarding out the design against hardware specs at the start of the project - and avoided months of wasted effort - that would be called "premature optimization".

    [1] https://dl.acm.org/doi/pdf/10.1145/356635.356640