New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I've mostly been submitting but reports through their interface as requested. Stuff like no server-side validation of country (I officially live in "United Steaks" in the state " "), broken links in documentation, CORS errors, etc.
I have a habit of breaking portals..
Thank you for the invite.
Was successful in breaking things.. ;0
Support tickets do send external emails however bug reports do not. Starting to lose track of the bugs I have reported..
I'll ask the community.. Should bug reports operate similar to support tickets with a different queue, so progress can be tracked and more details can be added?
Things may have changed in the couple weeks since this started? I haven't received any "form/guideline" so just using the "Report a bug" in the portal. May also be because I haven't had even 24 hours in the portal yet.
I actually kinda want to see this portal
Can someone please DM me the feedback instructions?
still waiting for the credits to deploy something
Just make a ticket
@crunchbits @benha any instructions for batch 3?
Email or account name?
Just opened a ticket with you.
Can a few people run this for several minutes and tell me if there is any output?
Running now.
I put in a ticket for 300+ packets/sec, 98% of which were ARP, but I see that you're filtering those out...
Edit: results:
Funnily enough, I had the ARP flood written up in a ticket but hadn't even submitted it yet.
But yeah, the ARP is being filtered out because I'm looking for control-plane traffic and unknown-unicast flooding. After I reported that, they applied a fix and it seems to work. I just want to double-check from the vantage point of other VMs.
That tcpdump filter should catch anything that's not IPv4, IPv6, or ARP (e.g. LLC and STP leaking through), as well as unknown-unicast traffic (IPv4/IPv6 datagrams arriving that are unicast that we receive but that are not actually intended for us, excluding ICMPv6 neighbor discovery/solicitation messages).
got nothing
0 packets captured
1336 packets received by filter
0 packets dropped by kernel
funny enough, i tested it on my other servers and somehow i see leaks...
Yep, quite a few providers here don't know how to set up proper isolation between VMs.
With one particular provider, I even got to see constant DNS answers being returned to someone else.
I can't hold the urge to ask @crunchbits @benha @skorupion to give me the code. It will be easier to debug than probing manually
Sure, but you'll probably be getting a free lifetime Syntaq PP VPS for doing QA anyway, even if you could do better with access to the source.
But even if you don't get the source, maybe getting a detailed description of the underlying architecture would help?
I started a DHCP server on a VM, mainly because I wanted to use netboot.xyz on a second VM and it was no longer working when manually entering a static IP, so I figured I would try router-on-a-stick to NAT the traffic through the second VM..
Instantly I could see 4 systems requesting IPs, including mine. They didn't receive the offer, that seemed to be filtered..
Weird that some traffic between VMs is filtered but not others.
Well.. This particular system is definitely beta..
Unknown-unicast traffic usually occurs because the bridge has forgotten which MAC is associated with an IP, so it sends it to everyone (which is why you can only see incoming traffic). It's common with VMs that haven't sent much traffic lately. But it should still be filtered.
On the contrary, I think this provider is doing it right by fixing it in beta rather than leaving it that way well into production like many other providers do!
Technically, putting minimum effort barely above the cut-off does maximize the return. But on the long run — and this is where minimum effort turns actively self-defeating — the payoff relies on their survival. Host deadpool rates are brutal , and in a hypercompetitive market (D'Aveni, 1994) any static advantage erodes on contact. The expected value of my arrangement isn't "free meal × forever"; it's the integral of service value over their survival function. Every piece of feedback that lowers their deadpool probability raises the net present value of my own compensation.
Which redefines what optimal feedback even is. Flagging defects is the floor; the high-effort play is pushing differentiation (Porter, 1980), because under monopolistic competition (Chamberlin, 1933) the only defensible margin is being distinct, not marginally cheaper than the hyperscaler. And note the recursion: stack transparency — the very thing I'm asking for — could itself be the differentiator. In a market where every plate is a lottery to chicken buyer , credible disclosure over hw/sw stacks is a Spence signal aimed at the whole customer base, not just at me.
Then the process argument: variance is the silent killer. Customer satisfaction runs on expectation disconfirmation (Oliver, 1980), and prospect theory (Kahneman & Tversky, 1979) tells us the loss function is asymmetric — one negative surprise destroys more goodwill than an equivalent positive surprise creates, so consistency beats occasional brilliance. That's Deming's whole thesis: you don't inspect quality in at the end of the line (that's me), you build it into the process so the defect never plates. Every API bugs I catch should die as an anecdote and be reborn as an SOP — measured, checkpoints, documented recipes — so the fix survives git rebase and no customer ever meets that defect again. SERVQUAL weights reliability above every other service dimension (Parasuraman, Zeithaml & Berry, 1988) for exactly this reason: a brand is nothing but a promise of low variance.
I didn't say the bare minimum! We definitely should be putting in effort.
But... why AI slop??
Bare minimum effort is still an effort.
Oh, it's nothing. I just want to put
on your mind
On the contrary?
Yes they seem to be putting in the effort but some of the bug fixes I wonder if they are just fixes that (will) cause other problems.
As an example I believe one of the networking fixes they put in has stopped the netboot.xyz image from getting IP network access. At first was able to use it by entering the static IP address, but if a VM was resized it stopped working. Day or two later it stopped working on not-resized VMs.
No, I hadn't broken my system (but the initial image was defective, has been since fixed) but since admins will use netboot.xyz for system recovery, I tried it.
I believe the thing that I will give props for is that 40GB of storage actually is based on 1024 math not 1000, 40GB actually is 40GB. That is, in my opinion, a bonus that will set them apart from competitors (if that stays). RAM isn't but maybe it will be in the future. Or maybe the storage thing is a bug that will be fixed too. haha
Isn't that exactly what this beta phase is for?
Yes?
That is why I said it is
Then you responded with 'on the contrary' which I thought was an odd response.
Ah, I thought you were criticizing the state of the way they were doing their testing. I was contesting that by saying that they were doing the right thing by testing everything in beta. Just goes to show that my reading comprehension needs work.
I'm interested.
update:
I'm not 167.17.73.76, but I am in the same subnet.
@benha @crunchbits ^
You're funny if you think @skorupion gets access
Yeah. I thought he got access to the git. Have you assessed the entirety of my report?