CommPulse

Yesterday, my Firebase database was suspended due to "Suspension of your Google Cloud Platform/API because it engaged in abusive activity consistent with hijacked resources." Until the database is reinstated, no one can use my app because the backend is completely unavailable. I want to make sure this type of suspension never happens again. I also want to prepare a disaster recovery plan so that, if Google suspends my Firebase project again, my application can continue working with minimal downtime. I have the following questions: 1. Independent Backup and Disaster Recovery Currently, I have Firebase and Google Cloud disaster recovery options, but if Google suspends my project, I cannot even access those backups because the entire project is suspended. As a solution, I am thinking of creating a separate backup system outside Google Cloud. My idea is: Create a script or service that runs on my own VPS. Every day, automatically back up all Firestore data to a completely separate database. Store the backups independently so they are still available even if my Firebase project is suspended. I also need to back up: Firebase Authentication (users and authentication data) Firebase Storage (uploaded files) My questions are: Is this architecture possible? How can I securely access Firebase Authentication data and store it in another database? How can I back up Firebase Storage files? Can I download them using signed URLs or another secure method? What is the recommended approach for implementing this entire backup system? 2. Switching to the Backup Database Without an App Update If my original Firebase project is suspended again, I want my Flutter app to connect to the backup database until Google reinstates the original project. My concern is that most users do not update the app immediately. My questions are: Is it possible to switch the backend from the original Firebase project to the backup server without requiring users to update the app? If it is possible, what is the recommended architecture? If it is not possible, what is the best approach using an app update? What disaster recovery strategy would you recommend for Flutter applications? 3. Protecting Firebase Service Account Credentials I believe my Firebase project may have been suspended because my Firebase service account JSON file (used for sending FCM notifications) was leaked. Previously, I stored the service account JSON file inside my Flutter project's assets folder. Although I enabled ProGuard/R8 code obfuscation to make reverse engineering more difficult, I now realize that the file can still be extracted from the APK. I researched this issue and received different advice: ChatGPT suggested that hardcoding the credentials in the application with code obfuscation provides some protection. Claude AI recommended never storing the service account in the app. Instead, it suggested keeping it on Cloud Functions or on a separate VPS and sending notifications from the backend. Based on your experience: Which approach is the most secure? Is using Cloud Functions better than hosting the credentials on a VPS? Is there an even better architecture than either of these approaches? What is the industry best practice for securely sending FCM notifications while preventing service account credential leaks? I would appreciate your recommendations and any additional security best practices to ensure that this type of suspension never happens again.

So we ran a proper SaaS audit this month. Our SSPM reported 340 managed apps, which looks reasonable on a dashboard. Then we pulled the raw OAuth grant data from Google Workspace and found another 180 apps that no one in IT knew that it existed. 40 of them had full Drive access. One was a project management platform that the marketing team signed up for in early 2024, and three people are still using it. We don’t have a problem with the tool, but the IT team found out about it during the audit. The SSPM flagged none, but I am thinking its because the apps were never provisioned through IT in the first place. Someone just clicked sign in with Google and that was it. They were living entirely outside the managed ecosystem. What are you all doing about the SaaS your SSPM will never see? submitted by /u/ParticularHat714 [link] [comments]

Just got the obligatory “are you enjoying Outlook” popup. I really hate these things. It’s an app. It’s a thing I use for work. I don’t want to yap with some bot about whether or not I do or don’t like new outlook old outlook, ancient outlook or lotus notes. These things are tools. Utilities. Might as well be a refrigerator. Damn, just make the thing work effectively and stop wrapping it in sparkles and leave me alone. Oh, and get off my lawn too, lol. submitted by /u/Psychological-Tie324 [link] [comments]

If you want to learn how to create AI agents using Microsoft's tools, I found this Microsoft Learn path to be a place to start. It includes subjects, like: - AI agent basics - Writing prompts - Using tools - Agent processes - Microsoft AI Foundry basics This learning path is free and you can go at your speed with Microsoft Learn : https://learn.microsoft.com/en-us/training/paths/develop-ai-agents-azure/?wt.mc_id=studentamb_551132 If you have already finished it I would like to know what you think about it or if you have other Microsoft Learn suggestions. submitted by /u/One-Asparagus-5229 [link] [comments]

We have an Azure File Share mounted on a Linux server using the SMB protocol. We have enabled Azure Files Diagnostic Settings and enabled on Delete Operation and are sending the logs to a Log Analytics Workspace. Our requirement is to identify which files are permanently deleted from the mounted file share and automate a report of those deleted files. During our testing, we observed the following: When a file is deleted from the Azure Portal (HTTPS/REST API): OperationName = DeleteFile This clearly indicates a delete operation. When a file is deleted from the mounted server over SMB: OperationName = Close Category = StorageDelete SmbCommandMinor = FileCloseAndDelete In my test environment, deleting a file ( rm file.txt ) generated the above SMB log, and the file was actually removed from the file share. However, in our production environment, we also see multiple entries with: Category = StorageDelete OperationName = Close but some of those files are still present in the Azure File Share. This suggests the application may be deleting and recreating or replacing files as part of its normal processing. Our queries are related to: Is Category = StorageDelete with SmbCommandMinor = FileCloseAndDelete expected to represent every SMB delete request, even if the file is later recreated? Is there any Azure diagnostic log or audit log that can definitively identify files that were permanently deleted over SMB? Is there any Microsoft-recommended approach to generate a daily/weekly report of deleted files from Azure File Shares? What would be the most cost-effective way to automate such a report? For example: Log Analytics scheduled query Azure Workbook Logic App Azure Automation Runbook Azure Function submitted by /u/LandSignificant4140 [link] [comments]

Resolve AI now charges for results instead of tokens. They say if their agent wastes tokens, that's their cost to eat, not yours. Datadog has made Agent Observability free for up to 40,000 LLM spans a month. They didn't announce it explicitly, they just changed the line at the bottom of their AI blog posts. Opsgenie will be shutting down in April 2027. PagerDuty wrote a post to win those customers, and put incident.io in a comparison table. incident.io hit back point by point. As said by incident.io "calling our AI "limited" is "like describing PagerDuty as a pager." NeuBird put up a page comparing itself to Datadog Bits AI. It's the best public summary of where Bits AI is right now. Bits AI SRE is now called Bits Investigation . It's billed in AI Credits sold in 500-credit bundles , and unused credits expire each month. Their remediation and detection features were shown at DASH 2026 but are still in Preview. Traversal says most AI SRE tools pull data too late. Their point is that the other tools query your observability APIs during the incident and get stuck behind rate limits. They stream the data ahead of time instead. PagerDuty has a new CEO as John DiLullo takes over, Jennifer Tejada moves to Executive Chair. They also shared four straight quarters of GAAP profit and a $100 million buyback. Everyone is now selling prevention, not just faster fixes. NeuBird wrote a buyer's checklist around it. Their test question: "Show me an incident you prevented that never generated an alert." Sherlocks AI shipped an automation builder. Pick a trigger, describe the job in plain English, choose where the result lands. Their pitch: " Describe the job. It runs ." The examples lean preventive rather than reactive, watching canary deploys, flagging infrastructure changes in PRs, tracking pod memory drift. Resolve AI is pushing background agents. Agents that keep running between incidents, watching deploys and doing checks. A customer quote sums it up: "The alerts are already investigated. The deployment summaries are already written." Traversal is renaming things. "Chat with Prod" is becoming "Production Support." "AI-Native Compressor" is becoming "Causal Indexer." Both old and new names are live on their site right now. Sources linked below in comments. submitted by /u/Holiday-Record7341 [link] [comments]

Hey everyone, I need to build a few DSM packages soon, so I’d love to brush up on my skills and get some practice in before taking on a real client project. Does anyone know if or how it’s possible to get access to the installation media and a demo/trial key to set up a small lab environment? Thanks in advance! submitted by /u/Linkboost512 [link] [comments]

I have supported part time a small non-profit company and while I know how important documentation is there just always was something else pressing that was more important. Well I am getting to the point where in the future I am probably going to be moving on and have started to work on trying at least for me document what they have at a high level. I assume and I know what happens when you do that but they have enough technical stuff that if the person actually knows what they are doing then they should be able based on a overview of the systems function dig into it and figure things out. I am not doing anything esoteric but I also have been doing this kind of stuff for *cough* many years. While small they have a lot of technology, just migrated the virtual environment to proxmox, they have AD environment with ADFS connected to m365, etc... I just captured the inventory for everything they have and was about to start writing up a word document that gives a high level for each server etc, layout of the network, vlans etc. I then started to think that maybe I should do something like a wiki or use something else. Although at a high level kind of leaning towards not having it online since it would pretty much give you a working layout of their environment and if compromised would be pretty nice to have. Just thought I would ask what are folks using for documentation, thanks. submitted by /u/bishoptf [link] [comments]

Recently a coworker granted Claude elevated access via SSH to a virtualization host (not a VM, an actual host). To perform a routine task he very well could have done himself. He doesn’t see an issue with this. I on the other hand (with 23yrs experience) see this as a huge security breach, and don’t trust AI todo my job, (or even that it’s doing what it says it’s doing) for me. I’m my opinion it’s a tool, not a human replacement. What’s your reaction, how would you react to this situation, or thoughts on the topic? Sure, ask AI how to perform a task, validate that it’s performing the task you asked, and nothing else- copy/paste the commands. Great. But removing the human verification & validation element- hell no. submitted by /u/xstrex [link] [comments]

submitted by /u/AlexThibaud [link] [comments]

Hi, I am an international student in Australia in bachelors of IT. In my next semester, I have to choose my majors. Now I am thinking of selecting "cloud engineering and IOT" (it is considered one major at my uni). I am interested in doing it, but the issue comes with choosing the right option. I have secured AZ-900 certification, but after searching and looking at Reddit posts, I have heard that certifications are a waste of money. I was going to do AZ-104 but dropped out. Now, I am very confused about whether this major and field would be a better option for me. I have a lot of interest in doing but looking at the current market and the AI revolution situation, I am very confused. I have the option for cybersecurity, but that field requires security clearances even for internships. Even if I go with cloud computing, I would need a proper roadmap on what to do and how to do it. YouTube is filled with these types of videos, but everyone has a different roadmap that also confuses me. I need some suggestions from people working in this industry. I am happy to share more details about my situation. Thank you for reading. submitted by /u/Hassan_121 [link] [comments]

It began with a bumpy start. I had just ordered my 4 vCore, 8GB memory VPS and having a (not really) special requirement I created a ticket. The good news was that I got a friendly "can do" reply - via a LET PM. The bad news was that I had to wait for more than a day for it actually happening. Same thing happened again, again a reaction only via LET PM. I don't have any idea why but it seems that the provider strongly prefers LET PMs over their own ticket system. Weird. But that's the only not positive thing I have to say. Since then perfectly happy sailing. Let me put it like this: I'm so happy with my new VPS that I wanted to purchase yet another one, a somewhat smaller 3 vCore one and was saddened to see that it isn't available anymore. Let's look at the data, based on over 50 runs. First as usual machine info, processor, and memory Version 2.5.0a, (c) 2018+ jsg (->lowendtalk.com) Machine: amd64, Arch.: amd64, Model: Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHz OS, version: FreeBSD 14.2, Mem.: 7.989 GB CPU - Cores: 4, Family/Model/Stepping: 6/85/4 Cache: 32K/32K L1d/L1i, 2M L2, 16M L3 Std. Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 cflsh mmx fxsr sse sse2 ss htt sse3 pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline aes xsave osxsave avx f16c rdrnd hypervisor Ext. Flags: fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx pat pse36 rdseed adx smap clflushopt clwb sha umip pku ospke syscall nx pdpe1gb rdtscp lm lahf_lm lzcnt AES? Yes InNested Virt.? Yes HW RNG? Yes ProcMem SC [MB/s]: avg 158.8 - min 54.6 (34.4 %), max 284.3 (179.1 %) ProcMem MA [MB/s]: avg 703.0 - min 580.0 (82.5 %), max 805.7 (114.6 %) ProcMem MB [MB/s]: avg 729.9 - min 671.4 (92.0 %), max 847.1 (116.0 %) ProcMem AES [MB/s]: avg 930.1 - min 909.1 (97.7 %), max 943.4 (101.4 %) ProcMem RSA [kp/s]: avg 66.6 - min 54.6 (82.0 %), max 76.4 (114.8 %) Don't be fooled by the somewhat mediocre single core performance. Yes, it strongly hints at high node occupancy, but then, at that ridiculously low price that was to be expected. Besides, I've seen similar numbers on VPS at double or higher cost. The two multi-core numbers ("MA" and "MB") however show a quite different picture, those 700+ MB/s results are really nice and so are the AES results. Only the RSA result, while acceptable, is a bit on the lower end, so that super-cheap VPS might be a bad choice for use cases that require lots of TLS handshakes (like. e.g. a very busy web server with hundreds of clients connecting each second). Otherwise and generally speaking a quite performant box; normally I'd expect that kind of performance beginning at about three times of what I've paid. --- Disk 4 KB - Buffered --- Write seq. [MB/s]: avg 2.61 - min 2.03 (77.8%), max 3.53 (135.4%) Write rnd. [MB/s]: avg 2.30 - min 1.87 (81.3%), max 3.04 (132.1%) Read seq. [MB/s]: avg 11.41 - min 10.21 (89.5%), max 13.37 (117.2%) Read rnd. [MB/s]: avg 8.03 - min 4.71 (58.7%), max 9.80 (122.1%) --- Disk 4 KB - Sync/Direct --- Write seq. [MB/s]: avg 2.58 - min 2.15 (83.3%), max 3.44 (133.3%) Write rnd. [MB/s]: avg 2.27 - min 1.95 (85.8%), max 2.72 (119.7%) Read seq. [MB/s]: avg 11.51 - min 10.24 (89.0%), max 13.36 (116.1%) Read rnd. [MB/s]: avg 8.15 - min 7.07 (86.7%), max 9.51 (116.6%) --- Disk 64 KB - Buffered --- Write seq. [MB/s]: avg 16.92 - min 14.26 (84.3%), max 21.97 (129.8%) Write rnd. [MB/s]: avg 18.35 - min 15.55 (84.8%), max 22.69 (123.7%) Read seq. [MB/s]: avg 914.98 - min 552.07 (60.3%), max 1457.16 (159.3%) Read rnd. [MB/s]: avg 90.95 - min 81.01 (89.1%), max 104.73 (115.2%) --- Disk 64 KB - Sync/Direct --- Write seq. [MB/s]: avg 5.01 - min 4.54 (90.7%), max 5.31 (106.0%) Write rnd. [MB/s]: avg 3.21 - min 2.63 (82.1%), max 3.40 (106.1%) Read seq. [MB/s]: avg 701.00 - min 591.23 (84.3%), max 994.96 (141.9%) Read rnd. [MB/s]: avg 88.03 - min 74.61 (84.8%), max 102.73 (116.7%) --- Disk 1 MB - Buffered --- Write seq. [MB/s]: avg 20.65 - min 17.86 (86.5%), max 26.36 (127.7%) Write rnd. [MB/s]: avg 42.50 - min 34.17 (80.4%), max 59.01 (138.8%) Read seq. [MB/s]: avg 1244.47 - min 1017.34 (81.7%), max 1786.52 (143.6%) Read rnd. [MB/s]: avg 416.87 - min 363.46 (87.2%), max 460.46 (110.5%) --- Disk 1 MB - Sync/Direct --- Write seq. [MB/s]: avg 12.58 - min 11.15 (88.7%), max 15.03 (119.5%) Write rnd. [MB/s]: avg 11.65 - min 10.64 (91.3%), max 13.22 (113.5%) Read seq. [MB/s]: avg 1220.14 - min 1060.32 (86.9%), max 1928.80 (158.1%) Read rnd. [MB/s]: avg 438.67 - min 372.63 (84.9%), max 499.07 (113.8%) --- Disk IOps (Sync/Direct) --- Write seq. [MB/s]: avg 5.87 - min 4.58 (78.0%), max 8.77 (149.4%) IOps : avg 1502.63 - min 1173.63 (78.1%), max 2246.17 (149.5%) Let's be honest, that's not the kind of disk performance that makes your jaw drop and you dance in joy - but neither is it crappy. Again, we're talking about a VPS that costs about $20 per year! And with that in mind I see no reason at all to complain, but rather a hint to not put the wrong kind of workload on the box; a web-server for a mid-size site with no more than a few hundred req/s should run fine, a hardcore DB based site probably not, in other words: easily good enough for about 80% of websites out there. --- Europe --- NO OSL mirror.neuf.no [F: 0] DL [Mb/s]: avg 487.3 - min 381.0 (78.2%), max 512.6 (105.2%) Ping [ms]: avg 21.4 - min 21.2 (99.1%), max 23.6 (110.3%) Web ping [ms]: avg 23.3 - min 22.3 (95.6%), max 39.5 (169.4%) UK LON lon.speedtest.clouvider.net [F: 0] DL [Mb/s]: avg 769.8 - min 225.9 (29.3%), max 1389.8 (180.5%) Ping [ms]: avg 6.8 - min 6.2 (91.0%), max 21.9 (321.5%) Web ping [ms]: avg 6.8 - min 6.2 (90.7%), max 21.9 (320.2%) NL AMS mirror.nl.leaseweb.net [F: 0] DL [Mb/s]: avg 629.2 - min 43.2 (6.9%), max 1665.0 (264.6%) Ping [ms]: avg 1.0 - min 0.9 (89.9%), max 1.7 (169.7%) Web ping [ms]: avg 11.7 - min 0.9 (7.7%), max 184.6 (1575.4%) DE FRA fra.lg.core-backbone.com [F: 0] DL [Mb/s]: avg 757.1 - min 442.6 (58.5%), max 1438.2 (190.0%) Ping [ms]: avg 6.3 - min 6.1 (97.2%), max 6.6 (105.2%) Web ping [ms]: avg 6.5 - min 6.3 (97.7%), max 7.7 (119.4%) FR mirrors.ircam.fr [F: 0] DL [Mb/s]: avg 426.2 - min 138.6 (32.5%), max 570.5 (133.9%) Ping [ms]: avg 19.1 - min 0.0 (0.0%), max 22.2 (116.2%) Web ping [ms]: avg 46.0 - min 0.0 (0.0%), max 785.1 (1707.6%) RO BUC mirror.efect.ro [F: 0] DL [Mb/s]: avg 162.4 - min 103.0 (63.4%), max 322.1 (198.3%) Ping [ms]: avg 45.8 - min 41.7 (91.0%), max 67.4 (147.1%) Web ping [ms]: avg 52.0 - min 41.7 (80.2%), max 169.5 (326.0%) GR UNK ftp.otenet.gr [F: 15] DL [Mb/s]: avg 86.1 - min 0.0 (0.0%), max 219.5 (255.1%) Ping [ms]: avg 36.8 - min 0.0 (0.0%), max 73.4 (199.4%) Web ping [ms]: avg 50.3 - min 0.0 (0.0%), max 534.1 (1062.3%) RU MOS speedtest.hostkey.ru [F: 0] DL [Mb/s]: avg 180.6 - min 93.2 (51.6%), max 270.4 (149.7%) Ping [ms]: avg 40.7 - min 40.6 (99.7%), max 41.4 (101.7%) Web ping [ms]: avg 47.2 - min 40.8 (86.5%), max 56.8 (120.4%) --- Asia / Oceania --- RU SIB mirror.truenetwork.ru [F: 0] DL [Mb/s]: avg 127.2 - min 104.6 (82.2%), max 134.3 (105.6%) Ping [ms]: avg 87.9 - min 84.4 (96.0%), max 127.3 (144.8%) Web ping [ms]: avg 90.7 - min 84.5 (93.1%), max 136.9 (150.9%) IN MU mirrors.piconets.webwerks.in [F: 0] DL [Mb/s]: avg 86.8 - min 79.2 (91.2%), max 94.4 (108.7%) Ping [ms]: avg 128.5 - min 118.9 (92.5%), max 130.9 (101.8%) Web ping [ms]: avg 133.0 - min 121.9 (91.7%), max 164.1 (123.4%) SG SGP mirror.aktkn.sg [F: 5] DL [Mb/s]: avg 33.0 - min 0.0 (0.0%), max 51.5 (156.0%) Ping [ms]: avg 168.3 - min 167.4 (99.5%), max 170.5 (101.3%) Web ping [ms]: avg 168.3 - min 167.4 (99.4%), max 170.5 (101.3%) JP TOK speedtest.tokyo2.linode.com [F: 0] DL [Mb/s]: avg 35.1 - min 21.8 (62.0%), max 47.8 (136.2%) Ping [ms]: avg 245.0 - min 236.6 (96.6%), max 262.0 (106.9%) Web ping [ms]: avg 248.2 - min 236.6 (95.3%), max 276.1 (111.3%) AU MEL ftp.au.freebsd.org [F: 58] DL [Mb/s]: avg 0.6 - min 0.0 (0.0%), max 37.5 (5900.0%) Ping [ms]: avg 301.8 - min 300.8 (99.7%), max 312.2 (103.4%) Web ping [ms]: avg 302.2 - min 300.9 (99.6%), max 326.1 (107.9%) --- Americas --- US DAL mirror.dal.nexril.net [F: 0] DL [Mb/s]: avg 99.0 - min 63.7 (64.3%), max 104.5 (105.6%) Ping [ms]: avg 110.2 - min 106.7 (96.8%), max 111.7 (101.4%) Web ping [ms]: avg 110.4 - min 106.8 (96.7%), max 112.3 (101.7%) US SFR mirrors.ocf.berkeley.edu [F: 0] DL [Mb/s]: avg 77.7 - min 74.9 (96.4%), max 79.5 (102.3%) Ping [ms]: avg 142.8 - min 142.2 (99.6%), max 146.0 (102.2%) Web ping [ms]: avg 143.0 - min 142.2 (99.5%), max 146.3 (102.3%) US LAX la.speedtest.clouvider.net [F: 0] DL [Mb/s]: avg 59.5 - min 30.8 (51.8%), max 87.4 (147.0%) Ping [ms]: avg 127.8 - min 126.4 (98.9%), max 131.2 (102.7%) Web ping [ms]: avg 128.9 - min 126.4 (98.0%), max 143.0 (110.9%) BR SAO ftp3.br.freebsd.org [F: 9] DL [Mb/s]: avg 37.8 - min 0.0 (0.0%), max 52.5 (138.7%) Ping [ms]: avg 199.8 - min 0.0 (0.0%), max 227.9 (114.1%) Web ping [ms]: avg 221.8 - min 0.0 (0.0%), max 321.3 (144.9%) --- Africa --- MA RAB mirror.marwan.ma [F: 57] DL [Mb/s]: avg 0.8 - min 0.0 (0.0%), max 27.0 (3439.2%) Ping [ms]: avg 33.2 - min 0.0 (0.0%), max 45.0 (135.4%) Web ping [ms]: avg 33.3 - min 0.0 (0.0%), max 47.2 (141.6%) I yet again see a box that's somewhat region-centric; not surprising for a really, really cheap VPS. Within Europe though, particularly the big 3 or 4 EU targets, performance is very decent at 400+ Mb/s. As for the rest of the world connectivity isn't poor either but what I'd call "so so". India 80+ Mb/s is quite decent, Japan about 35 Mb/s isn't really bad, Australia less than 1 Mb/s and plenty of failures is disappointing. But again we're talking about a dirt cheap VPS. Conclusion/verdict: An exceptionally good deal . I'm amazed about what about $20 per year can get you nowadays. Again, I find that VPS so amazing (for the price) that I actually wanted to get another @chunkserve box, that's something that happens less than once a year. Well done, chunkserve!

🖥 2 vCore - E5-2697A 💾 2GB Ram ⚡ Storage: 30GB SSD Boot 2TB Sata Storage 🌐 10TB Bandwidth @ 2Gbps 🚀 500Mbpps Connection (After Bandwidth Allowance used, speed decreased) 📡 1 IPv4 & /64 IPv6 🖥 Linux OS 🛡 Arbor DDoS Protected Network 🛠 Control Panel: Virtualizor ⏳ Support: 24x7 UK-Based Technical Support 📍 Maidenhead, United Kingdom Hosted ⚡ 24 Hour Activation 💰£4.50 GBP / $6.03 *per month *correct at posting time 👉 Order Now: https://my.xhosts.uk/?cmd=cart&action=add&id=744 🚀 Limited Stock VPS Deals! 🚀 ⚡ Performance Benchmark (YABS & Geekbench) *Speed @ 500Mbps after allowance As this is a launch offer - One per customer currently Comment order number for double bandwidth root@Storage-Yabs:~# curl -sL https://yabs.sh | bash # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2026-05-11 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sat Jun 13 08:20:48 PM UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 1 hours, 30 minutes Processor : Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz CPU cores : 2 @ 2599.980 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 1.9 GiB Swap : 256.0 MiB Disk : 29.4 GiB Distro : Ubuntu 22.04.1 LTS Kernel : 5.15.0-46-generic VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : Iomart Hosting Ltd ASN : AS20860 IOMART CLOUD SERVICES LIMITED Host : Iomart Managed Services Limited Location : London, England (ENG) Country : United Kingdom fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 71.58 MB/s (17.8k) | 451.36 MB/s (7.0k) Write | 71.77 MB/s (17.9k) | 453.74 MB/s (7.0k) Total | 143.36 MB/s (35.8k) | 905.11 MB/s (14.1k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 332.55 MB/s (649) | 328.78 MB/s (321) Write | 350.22 MB/s (684) | 350.67 MB/s (342) Total | 682.77 MB/s (1.3k) | 679.45 MB/s (663) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 1.59 Gbits/sec | 1.52 Gbits/sec | 2.30 ms Eranium | Amsterdam, NL (100G) | 1.55 Gbits/sec | 1.50 Gbits/sec | 9.31 ms Uztelecom | Tashkent, UZ (10G) | 614 Mbits/sec | 818 Mbits/sec | 95.3 ms Leaseweb | Singapore, SG (10G) | 289 Mbits/sec | 1.06 Gbits/sec | 175 ms Clouvider | Los Angeles, CA, US (10G) | 380 Mbits/sec | 591 Mbits/sec | 135 ms Leaseweb | NYC, NY, US (10G) | 561 Mbits/sec | 1.34 Gbits/sec | 71.2 ms Edgoo | Sao Paulo, BR (1G) | 215 Mbits/sec | 255 Mbits/sec | 178 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 1.59 Gbits/sec | 1.49 Gbits/sec | 2.29 ms Eranium | Amsterdam, NL (100G) | 1.55 Gbits/sec | 1.48 Gbits/sec | 9.28 ms Uztelecom | Tashkent, UZ (10G) | 643 Mbits/sec | 1.07 Gbits/sec | 93.8 ms Leaseweb | Singapore, SG (10G) | 236 Mbits/sec | 979 Mbits/sec | -- Clouvider | Los Angeles, CA, US (10G) | 458 Mbits/sec | 705 Mbits/sec | 135 ms Leaseweb | NYC, NY, US (10G) | 475 Mbits/sec | 1.34 Gbits/sec | 69.8 ms Edgoo | Sao Paulo, BR (1G) | 294 Mbits/sec | 154 Mbits/sec | 178 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 1023 Multi Core | 1836 Full Test | https://browser.geekbench.com/v6/cpu/18345033 SATA Stats Write root@Storage-Yabs:~# fio --name=seqwrite \ --directory=/data \ --size=2G \ --bs=1M \ --rw=write \ --iodepth=32 \ --direct=1 seqwrite: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=32 fio-3.28 Starting 1 process seqwrite: Laying out IO file (1 file / 2048MiB) Jobs: 1 (f=1) seqwrite: (groupid=0, jobs=1): err= 0: pid=4486: Sat Jun 13 19:41:03 2026 write: IOPS=828, BW=829MiB/s (869MB/s)(2048MiB/2471msec); 0 zone resets clat (usec): min=970, max=1626, avg=1165.46, stdev=45.20 lat (usec): min=1011, max=1666, avg=1203.62, stdev=46.10 clat percentiles (usec): | 1.00th=[ 1123], 5.00th=[ 1139], 10.00th=[ 1139], 20.00th=[ 1139], | 30.00th=[ 1139], 40.00th=[ 1156], 50.00th=[ 1156], 60.00th=[ 1156], | 70.00th=[ 1156], 80.00th=[ 1172], 90.00th=[ 1205], 95.00th=[ 1254], | 99.00th=[ 1352], 99.50th=[ 1418], 99.90th=[ 1549], 99.95th=[ 1614], | 99.99th=[ 1631] bw ( KiB/s): min=847872, max=849920, per=100.00%, avg=848896.00, stdev=1182.41, samples=4 iops : min= 828, max= 830, avg=829.00, stdev= 1.15, samples=4 lat (usec) : 1000=0.05% lat (msec) : 2=99.95% cpu : usr=4.37%, sys=6.40%, ctx=2054, majf=0, minf=11 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,2048,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=32 Run status group 0 (all jobs): WRITE: bw=829MiB/s (869MB/s), 829MiB/s-829MiB/s (869MB/s-869MB/s), io=2048MiB (2147MB), run=2471-2471msec Disk stats (read/write): vdb: ios=0/1978, merge=0/0, ticks=0/2235, in_queue=2234, util=94.63% Read root@Storage-Yabs:~# fio --name=seqread \ --directory=/data \ --size=2G \ --bs=1M \ --rw=read \ --iodepth=32 \ --direct=1 seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=32 fio-3.28 Starting 1 process seqread: Laying out IO file (1 file / 2048MiB) Jobs: 1 (f=1) seqread: (groupid=0, jobs=1): err= 0: pid=4489: Sat Jun 13 19:41:51 2026 read: IOPS=1873, BW=1874MiB/s (1965MB/s)(2048MiB/1093msec) clat (usec): min=418, max=1613, avg=530.45, stdev=39.43 lat (usec): min=419, max=1614, avg=530.66, stdev=39.44 clat percentiles (usec): | 1.00th=[ 494], 5.00th=[ 515], 10.00th=[ 515], 20.00th=[ 519], | 30.00th=[ 523], 40.00th=[ 523], 50.00th=[ 523], 60.00th=[ 529], | 70.00th=[ 529], 80.00th=[ 537], 90.00th=[ 545], 95.00th=[ 553], | 99.00th=[ 611], 99.50th=[ 701], 99.90th=[ 963], 99.95th=[ 1020], | 99.99th=[ 1614] bw ( MiB/s): min= 1872, max= 1880, per=100.00%, avg=1876.00, stdev= 5.66, samples=2 iops : min= 1872, max= 1880, avg=1876.00, stdev= 5.66, samples=2 lat (usec) : 500=2.34%, 750=97.22%, 1000=0.34% lat (msec) : 2=0.10% cpu : usr=2.29%, sys=16.58%, ctx=2060, majf=0, minf=267 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=2048,0,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=32 Run status group 0 (all jobs): READ: bw=1874MiB/s (1965MB/s), 1874MiB/s-1874MiB/s (1965MB/s-1965MB/s), io=2048MiB (2147MB), run=1093-1093msec Disk stats (read/write): vdb: ios=4054/15, merge=0/0, ticks=1861/39, in_queue=1899, util=92.13% IOPS root@Storage-Yabs:~# fio --name=randrw \ --directory=/data \ --size=1G \ --bs=4k \ --rw=randrw \ --iodepth=64 \ --direct=1 randrw: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=64 fio-3.28 Starting 1 process randrw: Laying out IO file (1 file / 1024MiB) Jobs: 1 (f=1): [m(1)][100.0%][r=36.8MiB/s,w=37.4MiB/s][r=9422,w=9569 IOPS][eta 00m:00s] randrw: (groupid=0, jobs=1): err= 0: pid=4492: Sat Jun 13 19:42:30 2026 read: IOPS=9359, BW=36.6MiB/s (38.3MB/s)(512MiB/14001msec) clat (usec): min=33, max=10704, avg=51.35, stdev=32.95 lat (usec): min=33, max=10705, avg=51.41, stdev=32.96 clat percentiles (usec): | 1.00th=[ 43], 5.00th=[ 44], 10.00th=[ 45], 20.00th=[ 50], | 30.00th=[ 51], 40.00th=[ 51], 50.00th=[ 52], 60.00th=[ 52], | 70.00th=[ 53], 80.00th=[ 53], 90.00th=[ 56], 95.00th=[ 58], | 99.00th=[ 68], 99.50th=[ 76], 99.90th=[ 123], 99.95th=[ 221], | 99.99th=[ 239] bw ( KiB/s): min=32744, max=38768, per=100.00%, avg=37450.37, stdev=1146.90, samples=27 iops : min= 8186, max= 9692, avg=9362.59, stdev=286.72, samples=27 write: IOPS=9363, BW=36.6MiB/s (38.4MB/s)(512MiB/14001msec); 0 zone resets clat (usec): min=34, max=13969, avg=53.52, stdev=40.98 lat (usec): min=34, max=13969, avg=53.65, stdev=40.98 clat percentiles (usec): | 1.00th=[ 44], 5.00th=[ 45], 10.00th=[ 47], 20.00th=[ 52], | 30.00th=[ 53], 40.00th=[ 53], 50.00th=[ 54], 60.00th=[ 54], | 70.00th=[ 55], 80.00th=[ 56], 90.00th=[ 58], 95.00th=[ 60], | 99.00th=[ 71], 99.50th=[ 85], 99.90th=[ 219], 99.95th=[ 235], | 99.99th=[ 318] bw ( KiB/s): min=33544, max=38416, per=99.98%, avg=37448.89, stdev=934.41, samples=27 iops : min= 8386, max= 9604, avg=9362.22, stdev=233.60, samples=27 lat (usec) : 50=21.08%, 100=78.59%, 250=0.32%, 500=0.01% lat (msec) : 4=0.01%, 20=0.01% cpu : usr=4.44%, sys=17.17%, ctx=262195, majf=0, minf=15 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=131040,131104,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: bw=36.6MiB/s (38.3MB/s), 36.6MiB/s-36.6MiB/s (38.3MB/s-38.3MB/s), io=512MiB (537MB), run=14001-14001msec WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=512MiB (537MB), run=14001-14001msec Disk stats (read/write): vdb: ios=129758/129955, merge=0/6, ticks=5825/8562, in_queue=16483, util=99.35%

Hey LET 👋 One year ago we introduced ourselves here as a brand-new provider out of Germany, and we're still here, still improving. Three people run ComputeBox. We operate our own hardware in Mölln (near Hamburg) powered by 100% self-generated renewable energy, and in Bremen. To mark year one, we're bringing back a fan-favourite deal and adding three more. 🎂 1-Year Anniversary Deals All plans are monthly prepaid, cancel anytime , except Deal 4 which is billed 6 months upfront. Deal 1, EPYC Milan (7763) | Hamburg CPU: AMD EPYC 7763 (Milan) RAM: 16 GB vCores: 6 Storage: 100 GB NVMe Traffic: 2 TB Network: 2 Gbit/s Backup Slots: 5 Backup Storage: 200 GB (off-site, dedicated backup DC ~3 km from main DC) Price: €7.99/mo incl. VAT · €6.71/mo net 👉 Order incl. VAT · Order excl. VAT YABS: # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2025-04-20 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sun Mar 29 08:59:04 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 17 hours, 0 minutes Processor : AMD EPYC 7763 64-Core Processor CPU cores : 6 @ 2445.404 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 15.6 GiB Swap : 0.0 KiB Disk : 96.8 GiB Distro : Ubuntu 24.04.4 LTS Kernel : 6.8.0-58-generic VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : CSN-CoLocation ASN : AS212341 Stephan Rakowski, trading as CSN-Solutions GmbH Host : CSN Solutions Location : Margetshöchheim, Bavaria (BY) Country : Germany fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 327.70 MB/s (81.9k) | 2.94 GB/s (46.0k) Write | 328.57 MB/s (82.1k) | 2.96 GB/s (46.2k) Total | 656.28 MB/s (164.0k) | 5.90 GB/s (92.3k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 4.85 GB/s (9.4k) | 5.88 GB/s (5.7k) Write | 5.11 GB/s (9.9k) | 6.27 GB/s (6.1k) Total | 9.96 GB/s (19.4k) | 12.15 GB/s (11.8k) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 1.90 Gbits/sec | 1.87 Gbits/sec | 73.7 ms Eranium | Amsterdam, NL (100G) | 1.61 Gbits/sec | 1.79 Gbits/sec | 66.9 ms Uztelecom | Tashkent, UZ (10G) | busy | 1.49 Gbits/sec | 97.1 ms Leaseweb | Singapore, SG (10G) | 348 Mbits/sec | 1.36 Gbits/sec | 197 ms Clouvider | Los Angeles, CA, US (10G) | 403 Mbits/sec | 1.24 Gbits/sec | 157 ms Leaseweb | NYC, NY, US (10G) | 522 Mbits/sec | 1.85 Gbits/sec | 86.0 ms Edgoo | Sao Paulo, BR (1G) | 211 Mbits/sec | 1.26 Gbits/sec | 197 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 1.41 Gbits/sec | 1.90 Gbits/sec | 63.8 ms Eranium | Amsterdam, NL (100G) | 1.60 Gbits/sec | 1.94 Gbits/sec | 65.4 ms Uztelecom | Tashkent, UZ (10G) | 712 Mbits/sec | 1.79 Gbits/sec | 96.2 ms Leaseweb | Singapore, SG (10G) | 374 Mbits/sec | 982 Mbits/sec | 198 ms Clouvider | Los Angeles, CA, US (10G) | 426 Mbits/sec | 1.30 Gbits/sec | 157 ms Leaseweb | NYC, NY, US (10G) | busy | 1.58 Gbits/sec | 85.9 ms Edgoo | Sao Paulo, BR (1G) | busy | 828 Mbits/sec | 192 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 1445 Multi Core | 6083 Full Test | https://browser.geekbench.com/v6/cpu/17347656 YABS completed in 13 min 24 sec Deal 2, EPYC Turin | Hamburg 💾 Backup-Focused CPU: AMD EPYC 9655 (Turin) RAM: 12 GB vCores: 3 Storage: 100 GB NVMe Traffic: 2 TB Network: 5 Gbit/s Backup Slots: 5 Backup Storage: 200 GB (off-site, dedicated backup DC ~3 km from main DC) Price: €8.99/mo incl. VAT · €7.55/mo net 👉 Order incl. VAT · Order excl. VAT YABS: # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2025-04-20 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sun Mar 29 09:19:05 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 17 hours, 18 minutes Processor : AMD EPYC 9655 96-Core Processor CPU cores : 3 @ 2599.998 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 11.7 GiB Swap : 0.0 KiB Disk : 96.9 GiB Distro : Ubuntu 25.04 Kernel : 6.14.0-15-generic VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : CSN-CoLocation ASN : AS212341 Stephan Rakowski, trading as CSN-Solutions GmbH Host : CSN Solutions Location : Margetshöchheim, Bavaria (BY) Country : Germany fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 507.85 MB/s (126.9k) | 4.36 GB/s (68.2k) Write | 509.19 MB/s (127.2k) | 4.38 GB/s (68.5k) Total | 1.01 GB/s (254.2k) | 8.75 GB/s (136.8k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 7.27 GB/s (14.1k) | 6.92 GB/s (6.7k) Write | 7.65 GB/s (14.9k) | 7.38 GB/s (7.2k) Total | 14.92 GB/s (29.1k) | 14.31 GB/s (13.9k) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 3.06 Gbits/sec | 3.20 Gbits/sec | 14.1 ms Eranium | Amsterdam, NL (100G) | 1.86 Gbits/sec | 3.93 Gbits/sec | 66.9 ms Uztelecom | Tashkent, UZ (10G) | 728 Mbits/sec | 2.45 Gbits/sec | 91.8 ms Leaseweb | Singapore, SG (10G) | 455 Mbits/sec | 1.48 Gbits/sec | 197 ms Clouvider | Los Angeles, CA, US (10G) | 530 Mbits/sec | 1.01 Gbits/sec | 154 ms Leaseweb | NYC, NY, US (10G) | 855 Mbits/sec | 3.01 Gbits/sec | 85.3 ms Edgoo | Sao Paulo, BR (1G) | 397 Mbits/sec | 9.44 Mbits/sec | 197 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 2.20 Gbits/sec | 3.80 Gbits/sec | 13.8 ms Eranium | Amsterdam, NL (100G) | 2.55 Gbits/sec | 3.86 Gbits/sec | 66.1 ms Uztelecom | Tashkent, UZ (10G) | 1.08 Gbits/sec | 1.92 Gbits/sec | 91.8 ms Leaseweb | Singapore, SG (10G) | 473 Mbits/sec | 1.18 Gbits/sec | 197 ms Clouvider | Los Angeles, CA, US (10G) | 547 Mbits/sec | 946 Mbits/sec | 154 ms Leaseweb | NYC, NY, US (10G) | 856 Mbits/sec | 2.84 Gbits/sec | 85.4 ms Edgoo | Sao Paulo, BR (1G) | 209 Mbits/sec | 776 Mbits/sec | 193 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 2531 Multi Core | 6403 Full Test | https://browser.geekbench.com/v6/cpu/17347898 YABS completed in 11 min 21 sec Deal 3, EPYC Turin | Bremen 🌐 Traffic Beast Same specs as Deal 2, but optimised for bandwidth instead of backup space. CPU: AMD EPYC 9655 (Turin) RAM: 12 GB vCores: 3 Storage: 100 GB NVMe Traffic: 15 TB Network: 5 Gbit/s Price: €8.99/mo incl. VAT · €7.55/mo net 🎟️ Use coupon code EEUQ65L4 for 10% off, every billing cycle, limited to 50 VMs. 👉 Order incl. VAT · Order excl. VAT YABS: # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2025-04-20 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sun Mar 29 09:02:00 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 16 hours, 58 minutes Processor : AMD EPYC 9655 96-Core Processor CPU cores : 3 @ 2599.996 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 11.7 GiB Swap : 0.0 KiB Disk : 96.9 GiB Distro : Ubuntu 25.04 Kernel : 6.14.0-15-generic VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : LWLcom GmbH ASN : AS47277 LWLcom GmbH Host : ComputeBox HB1 Location : Flintbek, Schleswig-Holstein (SH) Country : Germany fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 707.32 MB/s (176.8k) | 5.11 GB/s (79.9k) Write | 709.19 MB/s (177.2k) | 5.14 GB/s (80.3k) Total | 1.41 GB/s (354.1k) | 10.25 GB/s (160.2k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 6.13 GB/s (11.9k) | 6.56 GB/s (6.4k) Write | 6.46 GB/s (12.6k) | 7.00 GB/s (6.8k) Total | 12.59 GB/s (24.5k) | 13.57 GB/s (13.2k) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 2.61 Gbits/sec | 3.89 Gbits/sec | 26.5 ms Eranium | Amsterdam, NL (100G) | 3.80 Gbits/sec | 3.99 Gbits/sec | 6.95 ms Uztelecom | Tashkent, UZ (10G) | 891 Mbits/sec | 2.32 Gbits/sec | 84.9 ms Leaseweb | Singapore, SG (10G) | 374 Mbits/sec | 896 Mbits/sec | 159 ms Clouvider | Los Angeles, CA, US (10G) | 445 Mbits/sec | 1.30 Gbits/sec | 153 ms Leaseweb | NYC, NY, US (10G) | 446 Mbits/sec | 2.68 Gbits/sec | 93.0 ms Edgoo | Sao Paulo, BR (1G) | 296 Mbits/sec | 1.20 Gbits/sec | 198 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 2.06 Gbits/sec | 3.88 Gbits/sec | 26.5 ms Eranium | Amsterdam, NL (100G) | 3.85 Gbits/sec | 3.94 Gbits/sec | 6.92 ms Uztelecom | Tashkent, UZ (10G) | 1.07 Gbits/sec | 6.40 Mbits/sec | 84.9 ms Leaseweb | Singapore, SG (10G) | 550 Mbits/sec | 1.40 Gbits/sec | 159 ms Clouvider | Los Angeles, CA, US (10G) | 188 Mbits/sec | 1.41 Gbits/sec | 153 ms Leaseweb | NYC, NY, US (10G) | 503 Mbits/sec | 2.77 Gbits/sec | 92.9 ms Edgoo | Sao Paulo, BR (1G) | 279 Mbits/sec | 635 Mbits/sec | 198 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 2589 Multi Core | 6678 Full Test | https://browser.geekbench.com/v6/cpu/17347681 YABS completed in 12 min 3 sec Deal 4, EPYC Turin | Bremen 📦 6-Month Prepaid ⚠️ This deal is billed 6 months upfront (€32.94 incl. VAT · €27.66 net). CPU: AMD EPYC 9655 (Turin) RAM: 6 GB vCores: 2 Storage: 60 GB NVMe Traffic: 10 TB Network: 5 Gbit/s Price: €5.49/mo incl. VAT · €4.61/mo net (6 months prepaid) 👉 Order incl. VAT · Order excl. VAT YABS: # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2025-04-20 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sun Mar 29 09:19:07 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 17 hours, 14 minutes Processor : AMD EPYC 9655 96-Core Processor CPU cores : 2 @ 2599.996 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 5.8 GiB Swap : 0.0 KiB Disk : 58.0 GiB Distro : Ubuntu 24.04.4 LTS Kernel : 6.8.0-58-generic VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : LWLcom GmbH ASN : AS47277 LWLcom GmbH Host : ComputeBox HB1 Location : Flintbek, Schleswig-Holstein (SH) Country : Germany fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 610.07 MB/s (152.5k) | 6.57 GB/s (102.7k) Write | 611.68 MB/s (152.9k) | 6.61 GB/s (103.3k) Total | 1.22 GB/s (305.4k) | 13.18 GB/s (206.0k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 9.20 GB/s (17.9k) | 9.75 GB/s (9.5k) Write | 9.69 GB/s (18.9k) | 10.40 GB/s (10.1k) Total | 18.89 GB/s (36.8k) | 20.16 GB/s (19.6k) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 2.03 Gbits/sec | 3.84 Gbits/sec | 21.7 ms Eranium | Amsterdam, NL (100G) | 3.84 Gbits/sec | 3.99 Gbits/sec | 6.93 ms Uztelecom | Tashkent, UZ (10G) | 812 Mbits/sec | 2.09 Gbits/sec | 86.2 ms Leaseweb | Singapore, SG (10G) | 364 Mbits/sec | 802 Mbits/sec | 157 ms Clouvider | Los Angeles, CA, US (10G) | 476 Mbits/sec | 1.04 Gbits/sec | 153 ms Leaseweb | NYC, NY, US (10G) | 369 Mbits/sec | 2.52 Gbits/sec | 92.7 ms Edgoo | Sao Paulo, BR (1G) | 352 Mbits/sec | 896 Mbits/sec | 198 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 2.26 Gbits/sec | 3.89 Gbits/sec | 21.6 ms Eranium | Amsterdam, NL (100G) | 3.77 Gbits/sec | 3.94 Gbits/sec | 6.92 ms Uztelecom | Tashkent, UZ (10G) | 625 Mbits/sec | 1.90 Gbits/sec | 86.2 ms Leaseweb | Singapore, SG (10G) | 436 Mbits/sec | 1.32 Gbits/sec | 157 ms Clouvider | Los Angeles, CA, US (10G) | 561 Mbits/sec | 952 Mbits/sec | 153 ms Leaseweb | NYC, NY, US (10G) | 471 Mbits/sec | 2.38 Gbits/sec | 92.7 ms Edgoo | Sao Paulo, BR (1G) | 225 Mbits/sec | 1.14 Gbits/sec | 199 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 2621 Multi Core | 4712 Full Test | https://browser.geekbench.com/v6/cpu/17347906 YABS completed in 12 min 21 sec 🖥️ GPU VMs, RTX 4000 ADA | Hamburg Looking for GPU compute? We also offer VMs backed by NVIDIA RTX 4000 ADA GPUs, hosted in Hamburg. Available directly via our panel, no ticket needed. 🎟️ Use coupon code 1FB1Z0BG for 15% off every billing cycle on all RTX 4000 ADA VM orders. 👉 Order here 🔍 Looking Glass Hamburg: lg.computebox.de Bremen: lg-hb.computebox.de ❓ FAQ What payment methods do you accept? PayPal and credit card via Stripe. No crypto. How does backup storage work? Backup storage is billed based on actual data stored, not your full disk size. If your VM uses 10 GB, only 10 GB of backup space is consumed, not the full 100 GB disk allocation. Can I add more traffic, storage or backup space? Yes. Additional traffic, disk storage, backup space and backup slots (subject to availability) can be added self-service through the panel. Package upgrades (more CPU cores or RAM) are not available, these are fixed deals. Do you support rDNS? Yes. IPv4 rDNS is available in both Hamburg and Bremen. IPv6 rDNS is currently available in Bremen only, we are working on bringing it to Hamburg. Are these deals recurring? Yes, the price is fixed monthly. No contract, cancel anytime. Deal 4 is prepaid 6 months upfront. About ComputeBox 🇩🇪 Own hardware in Germany, Mölln/Hamburg and Bremen ♻️ 100% renewable energy at our Hamburg site 💾 Off-site backups at a dedicated backup DC ~3 km from the main datacenter (Hamburg) 🔧 KVM virtualisation, NVMe storage, IPv4 + IPv6 included 📊 Self-service add-ons for traffic, storage and backup space via the panel 🌐 computebox.de -The ComputeBox Team

Nobody writes about this, so here are our dates and numbers while they're fresh. Letter of Validation on 31 July 2026, Google accepted it the next day. Two weeks, roughly, start to finish. One thing that confused us early: Tier 2 is called AL1 now (Tier 3 is AL2). Google's emails still say Tier 2, the lab's portal says AL1, same thing. What you're graded on is the ADA CASA Test Guide v2.1.1, 48 checks, free on GitHub. Scope review comes first, and it's where we nearly lost We're Mailneo , an email marketing tool with a unified inbox built in, so Gmail isn't a side feature for us, it's the product. That means gmail.modify . Which is restricted. Which means CASA. Google wrote back suggesting we swap gmail.modify for gmail.readonly + gmail.send . We said no, using the "unable to use narrower scopes" option: messages.modify , messages.trash and messages.untrash only accept mail.google.com or gmail.modify . So the pair they suggested breaks inbox organisation completely, and readonly is restricted anyway, so you save nothing on CASA by switching. We quoted the methods and the exact scopes each takes, straight out of the API reference. They accepted it, no further argument. Worth knowing, because that suggestion is a form letter. If narrower scopes genuinely can't do the job, say so, but bring receipts. Oh, and an earlier round failed on "app functionality" for a dumb reason: our trial paywall locked the Google reviewer out. Comp their account at the database level, then log in as them once and dismiss whatever modals pop up. What we paid TAC Security, Premium plan, unlimited revalidations. Lists at $855. We paid $794 after asking about a discount, so, ask. Basic is cheaper but only two rescan cycles. The scan OWASP ZAP through TAC's ESOF platform. Ran 28 July, about three hours, results the same day. 14 findings: 0 critical, 0 high, 1 medium, 4 low, 9 informational. All of it has to be fixed or formally disputed. Yes, including the informational ones. The SAQ 55 yes/no questions, each needing a written justification. ASVS derived: trust boundaries, where you enforce access control, password storage, sessions, TLS, input validation, dependencies, logging. If you're full stack, basically all of it applies. Answer like you're citing evidence. "Yes, we use bcrypt" gets you a follow-up email. "Yes, bcrypt at cost factor N, in this file, per NIST 800-63B 5.1.1.2" doesn't. And own your gaps. The SAQ caught a real one for us: minimum password length was 8, which fails. We bumped it to 12 and said exactly that in the answer. Cost us nothing. Overselling yourself is what drags you into a ten-email thread. They came back twice wanting evidence, once on how we encrypt stored Google user data, once on three specific SAQ items. Command output beats prose. For "can you restore your database" we sent raw RDS output showing backup retention and PITR. For "screenshot your encrypted data" we didn't want to export customer rows, so we ran our real encryption code against a fake payload of the same shape: plaintext in, ciphertext out, tampered record rejected. Fine by them. Things I'd tell past us Start the day the deadline email lands. We passed scope review back in January, never booked the assessment, and the whole verification lapsed. Redoing scope review hurt far more than the assessment did. Grade yourself against the Test Guide before you pay anyone. It's free and it's literally the rubric. Every finding you kill early is a rescan you don't burn. Run npm audit first. Vulnerable dependencies are the usual blocker and they eat the most calendar time. Everything else is fast by comparison. On a managed host, some findings are just your platform (CDN CORS headers, Server header, caching). Those want a written justification, not a code change. You do this again every 12 months. Ours is up around July 2027, reminder already set for May. Ask me anything. submitted by /u/Neither-Bass2083 [link] [comments]

2 Days ago RealVNC ended public access for Viewer 7. Now Connect Viewer 8 is the only publicly accessible version and requires a RealVNC account. "The RealVNC Classic Viewer (v7) will continue to be available for customers with a Premium or Enterprise plan to download from the RealVNC Portal." Source: https://help.realvnc.com/hc/en-us/articles/35745908986653-Important-changes-to-RealVNC-Viewer-Information-and-FAQs Time to make the move to open source VNC implementations. submitted by /u/ZenAdm1n [link] [comments]

Disclosure: I built this open-source tool. I kept running into a subtle GCP problem: the active project in `gcloud config` can differ from the project and quota project used by Application Default Credentials. That means `gcloud` may appear to be configured for development while Python, Node.js, Terraform or another SDK is still operating with a different ADC context. I built **gcpctx** to manage these pieces as one named context: - active Google Cloud project - active account - gcloud configuration - Application Default Credentials - ADC quota project - optional repository-local context Example: ```bash npm install -g gcpctx gcpctx init dev gcpctx use dev gcpctx doctor The goal is not to replace IAM or make deployments magically safe. It is to make the effective local GCP context explicit and easier to verify. Source: https://github.com/UriBer/gcpctx npm: https://www.npmjs.com/package/gcpctx I would especially appreciate feedback on: How you currently switch between GCP environments. Whether you have encountered gcloud/ADC context mismatches. Which workflows should be supported next: Terraform, PowerShell, CI or AI coding agents? submitted by /u/chilkibilki [link] [comments]

I got a very not expected 500+ euros bill from Azure, which is very hard for me to understand. I used the agents on the marked day probably, but not nearly as they reported, and even technically speaking, this usage is waaay over Azure's model limit. I have a limit of 40k tokens a minute, which is annoying sometimes, but it (should) help prevent cases like this. The graph of input token used show a minute with over 4M tokens. https://preview.redd.it/xc2ei9lcirgh1.png?width=826&format=png&auto=webp&s=20bacbff3d4596890a2c990c25a6fdc67efb67b5 That does not really reflect my use (you can see earlier that evening a small usage of few hundred tokens, that is usually my usage and the rate limit). Did anyone encounter something like that, or maybe someone can help me understand how this was possible? I am assuming they made a mistake honestly submitted by /u/hummus4everyone [link] [comments]

Looking for a Sofia (Bulgaria) VPS from a privacy-friendly host — one that values online privacy and free speech, no-KYC, and takes crypto. Specs I need: 6 GB RAM 4 CPU 24 TB bandwidth NVMe (disk size doesn't matter — 40–60 GB is fine) KVM A few questions: Who do you recommend in Sofia specifically? Do they take crypto and allow monthly billing? Are they relaxed about proxy/tunnel traffic? Thanks!

Ich habe bei Kiro ein Abo abgeschlossen temporiere gedacht für einen Monat. Problem einer Geschichte ist ich kann das Abo nicht mehr ab bestellen und Sie buchen weiterhin ab. Ich habe mich dot an den Support gewandt. Und keiner hat geantwortet. Ich hab's wieder getan und wieder und wieder und wieder. Keine Antwort weiterhin Abbuchungen. Jetzt ist die Frage wie komme ich an den AWS Support ran? Weil das Ganze anscheinend über AWS läuft submitted by /u/Ramba22187 [link] [comments]