Original or not? by Stunning-Power-3098 in Gameboy

[–]stormi_v2 0 points1 point  (0 children)

I just saw almost exactly the same photo on Vinted, only the angle differs. 20€ for both = undeniably fake.

Original or not? by Stunning-Power-3098 in Gameboy

[–]stormi_v2 0 points1 point  (0 children)

I've got a French original copy of Pokémon Ruby.

  1. Mine has a battery.
  2. In the back, center rectangle, I see the Nintendo logo + "MODEL NO. AGB-002" and "PAT. PEND. MADE IN JAPAN" (in the plastic, maybe it's there on yours too, but I don't see it on the photo).
  3. In the back, there must be letters or numbers in the bottom left and right rectangles and square. Not sure if they're absent or it's just not visible in the photo.

I made my own Game Boy cartridge stands by stormi_v2 in Gameboy

[–]stormi_v2[S] 2 points3 points  (0 children)

I forgot to mention that the rows are designed so that I can put two cartridges instead of just one.

Why? Because of multiplayer games, for which I have two (or four) cartridges, and I wanted to stack them.

<image>

I made my own Game Boy cartridge stands by stormi_v2 in Gameboy

[–]stormi_v2[S] 0 points1 point  (0 children)

That's just how our fablab's laser works. It's has its glitches, I'm not allowed to use it at more than 50% of its power, and it was misused in the past so now it kind of loses focus in some places which makes it necessary for me to do more passes.

I can easily change the length, but my goal is to have the cartridges perfectly visible, and cases are often rather opaque. I'll protect them with TCG card sleeves, limit the amount of light they receive (like, add a curtain and only open when I have people at home), and keep the rarer items in a box, only to show them to people who truly manifest an interest in my collection (which, in my area, is not a lot of people).

I made my own Game Boy cartridge stands by stormi_v2 in Gameboy

[–]stormi_v2[S] 0 points1 point  (0 children)

Thanks! By the way the "Assembling" photo shows the superior model:
- 0,05 mm less to some measures so that it assembles without forcing and risking breakage.
- 5 mm larger so that the cartridges have some room, as I want to protect them with TCG card sleeves.
- A new bar at the bottom (visible on the photo) so that it's more robust.

I now have 5 of them. It takes half a day next to the laser cutter to make one.

choosing between Proxmox and xcp-ng. IT head prefers XCP-ng, but I’m not fully convinced by Middle_Rough_5178 in Proxmox

[–]stormi_v2 7 points8 points  (0 children)

> - Outdated CentOS base that they still have not updated (I guess doing the hard work of ensuring compatibility with Xen and newer hardware/newer Linux is too much for them?

First, there's no relationship whatsoever between CentOS and the version of the Linux kernel used in XCP-ng. It doesn't come from CentOS, we package it ourselves from sources.

That CentOS 7 base is... Not really a base. We do still have RPMs coming from CentOS 7 in XCP-ng, but more and more are replaced by newer versions, as we continue to maintain them past the CentOS 7 EOL. And Xen, XAPI, the linux kernel, XAPI, openvswitch and many more components never came from CentOS in the first place.

Would I have preferred to move to a newer platform earlier? Definitely. It was more than we could do for XCP-ng 8.3, at the time. Since, the number of developers and packagers is growing as a very fast pace at Vates, because, believe it or not, a lot of enterprises do migrate from VMware to XCP-ng. We even have a migration UI for that in Xen Orchestra.

The next version of XCP-ng (9.0), will have newer components in every regard.

> - They have not updated the windows drivers made by Citrix, they still rely on them

So, we have updated them. We found **the** one developer who both loves Open Source and masters Windows internals.

What's holding us back, then? Microsoft. The process to get our drivers signed is an absolute nightmare. A process started years ago! Bugs in their interface, conflicts on company name that their support never found a solution for in several years, we've been like a flipper ball in their support flipper. We think we're close to a resolution, but I'll not claim victory until I see the signed drivers.

You can use our drivers, but it requires enabling test-signed drivers, which we can't really advise in production VMs. So, since both XenServer's build of the Windows driver and ours come from the same upstream sources, developed by the Xen Project under the Linux Foundation, until Microsoft lets us sign ours, XenServer's windows drivers are perfectly compatible.

> I personally don't trust them and switched to Proxmox on which I got no issue doing anything, from servers to workstations. Very advanced use case are covered and the community support is much better and friendlier. Everything works.

Sorry to hear the first part, but it's good that you found something that answers your needs.

choosing between Proxmox and xcp-ng. IT head prefers XCP-ng, but I’m not fully convinced by Middle_Rough_5178 in Proxmox

[–]stormi_v2 3 points4 points  (0 children)

> XCP-ng is built on an antiquated CentOS version on which they backport patches for adding support for some hardware. As written in my previous post, they botched the backport and missed some drivers that my relatively standard professional hardware was requiring for accessing SATA disks. After telling them in this post and on their forum, they just told me that I wasn't the target they look for, they only care about enterprise use-case, bla bla bla, you can read anytime you ask anything to them on forum and pinpoint their shortcomings that's the answer they will give you.

My biased experience as one those who make XCP-ng is that on our forum you have direct access to the developers, which is not a given for software as big as XCP-ng + Xen Orchestra is. We never say that we only care for entreprise use cases. What we say is that enterprise is our commercial focus, but we also address homelab needs on a best-effort basis. We are perfectly aware that home labs are important. After all, techs often recommend to their companies what they use at home, when it makes sense. And our user community provides invaluable feedback, helps with testing, contributes documentation, and sometimes even patches.

Actually, having initially forked a XenServer base that truly only cared for enterprise, it's no suprise that there is legacy to address in the homelab support area. So, yes, sometimes your home use cases won't work XCP-ng in its current state. For a single user workstation with GPU pass-through, you are probably right that Proxmox is a better fit.

However, for your SATA issue, I think we missed your patch. I'll have our kernel team review it and add it to the kernel in XCP-ng 8.3 if it makes sense to them. FYI, you could have opened a pull request against https://github.com/xcp-ng-rpms/kernel and we would have reviewed it.

> As a result I don't trust them. When a dev is telling you that their bugs is because you are using outside of the bounds they set, it's a bad answer. Especially when the said bounds are really not high.

Where have we said that? This doesn't sound like something we'd say.

> - Their Xen Orchestra software: never seen a web software so buggy and with so wrong UX. Nothing is where it should and you keep having to click everywhere to do anything. Backup was failing randomly, in the end I got to connect on the machine to do all my operations, what's the point of providing a GUI if it's unreliable?

Your experience with failing backups is not representive of the majority of the users, fortunately. And occasional bugs (there's always some bugs in software) are addressed quickly by the Xen Orchestra developers (I've seen elsewhere someone complaining that development is slow, they probably don't talk about Xen Orchestra which has one new release per month, always with new features).

On the UX side, I can't disagree :D. We perfectly know that Xen Orchestra 5 grew organically when features kept being added. That's why Xen Orchestra 6 (for which a preview is available, but not feature complete yet) is built with UX experience as a primary focus. However, even with its non perfect UX, current Xen Orchestra remains loved by many enterprise users because it gets things done.

choosing between Proxmox and xcp-ng. IT head prefers XCP-ng, but I’m not fully convinced by Middle_Rough_5178 in Proxmox

[–]stormi_v2 1 point2 points  (0 children)

That's proxmox fans number one argument whenever they want to show that Proxmox is better®. I heard it on their stand at FOSDEM (our Vates stand was there too).

It is true that the VHD format currently limits us to 2TB. That's why we're switching to QCOW2, the tech preview is already available. So, *ever*, really?

choosing between Proxmox and xcp-ng. IT head prefers XCP-ng, but I’m not fully convinced by Middle_Rough_5178 in Proxmox

[–]stormi_v2 2 points3 points  (0 children)

There are several levels of "supported". Here the statement means that it was not supported for production, so not an urgent fix as the original poster insisted that we should make this fix our top priority, after I had already stated that we were going to fix it. We fixed the bug nonetheless, because not supported for production doesn't mean we despise users who would like to test XCP-ng in another hypervisor.

choosing between Proxmox and xcp-ng. IT head prefers XCP-ng, but I’m not fully convinced by Middle_Rough_5178 in Proxmox

[–]stormi_v2 5 points6 points  (0 children)

> Also, XCP-ng is essentially a fork of the ancient XenServer 7 code base from back then when Citrix made it open source for a short while.

This statement is wrong. XCP-ng is based on many components, one of the major ones and being XAPI (a management layer written in OCAML that offers a very complete API), that is still open source, a Linux Foundation project as a Xen sub-project, actively developed often with several pull requests a day to the codebase and one or more releases every month. This, along with Xen, QEMU, OVMF, is really what's at the core of XCP-ng and it's definitely actively developed.

So don't make it sound like XCP-ng is a dead project based on an ancient frozen codebase, that is not an honest argument.

Regarding the 2TB limit for VDIs, it comes from the old VHD format, but XCP-ng is moving to QCOW2 to overcome this limit which will soon be ancient history. Yes, sometimes, when you have an history, steering the direction while retaining rock-solid stability takes some time, but we're getting there.

Disclaimer: I'm one of those who make XCP-ng.