Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/14/25 in all areas

  1. Don't you worry! We have plans for you brave testers out there to keep you on a "beta" track that lets you test out the goodies as we're building them. Basically we will have feature-tagging so we can enroll certain users in new beta features for testing before they are ready for the stable track. When we get to that phase, more will be revealed 😉
    2 points
  2. Exactly! It's one of the reasons I want to build a comprehensive hardware database for HexOS (obviously opt-in). There are a lot of details with hardware that aren't exposed when buying that we could start to map for folks who took the plunge without the insights. Boot up, run a little scan of how the IOMMU groups layout, what happens when you try to pass through a GPU, etc. and then create a filterable database for users to search and get more details. So many ways to improve UX here beyond just the software.
    1 point
  3. I’m not saying it’s impossible. There are guides online for migrating bare metal to KVM, Proxmox, VirtualBox, etc. However, this involves diving straight into a lot of advanced topics. My recommendation would be to back up your data and do a clean setup of KVM. You’ll learn a lot if you go with QEMU + KVM, but if you want to get things up and running quickly and efficiently, Proxmox is a solid alternative.
    1 point
  4. For example on my board, the OCuLink setting was set to PCIE by default and instead of a BIOS option, I had to move a jumper position on the board (drives don't get detected otherwise). The FAN controls are not in the BIOS, but on the BMC and are adjusted either in the IPMI page (not in my case), or via a command line tool, such as ipmitool (had to contact ASRock Rack support to get the commands, as they might differ b/w boards). The board has a special 24 to 4 ATX power adapter for the PSU cable. Be super careful here, as the board has two of these 4 pin power sockets and one of them is for power out - check the manual to see which is which and avoid damaging the board. A couple of tips about the case: You can actually plug in two 2.5 SATA SSDs if you use one screw per SSD and place them slightly tilted upwards, parallel to each other If you don't mind the aesthetics, you can actually remove the front metal panel for better airflow and even replace the 140mm fan with a better one (Some ppl use a BeQuiet, I went for a Noctua)
    1 point
  5. I love this idea and wonder if there is an API we could attach to that would let us report the power usage through our UI to avoid needing another app. Definitely stickying this for the future.
    1 point
  6. Thanks for catching this. I guess a AsRock Rack E3C256D2I Mini ITX Server Motherboard would be a better fit. Other than the need for OCuLink cables for the SATA, what other server motherboard quirks should I expect? Haven't done a lot of builds so I'd be interested in your insights.
    1 point
  7. 1 point
  8. This may not be the right place to make this argument, and I fully understand your plans may be firm and I am wasting my time by saying this. However, I would argue you almost certainly have a captive base of enthusiasts beta-testing your product rather than a high percentage of normies. (I apologize for that term; I can't think of a better word and don't mean it as an insult to anyone.) Given that assumption, it would seem that the phases are almost backward in an ideal world. Enthusiasts are likely going to go the extra distance to get what they want running on their NAS whether they have a HexOS way of doing it, or if they have to do it from TrueNAS. It would make more sense to have the custom docker/deployment script loader available first, with a suitable warning of dragons and dangers ahead, and provide an open-source example of a curated script so the community can start making and sharing custom app deployment scripts the HexOS way. Maybe have a forum section for sharing and collaborating/improving the scripts. Then you would already have a portfolio of proven community developers once you are ready to recruit, and (if you so choose) you can give out a "HexOS stamp of approval" to well-designed community app deployments. Finally, for the popular yet difficult apps that require a demanding configuration/deployment, work on curating them yourself later. I understand that you might need to make a few curated apps to define the "HexOS" way of app deployment and to develop a best practices guide for the community before allowing custom deployments, but by just opening the door, I suspect you will have a very nice catalog before you know it. Furthermore, I suspect the community will naturally develop deployments for popular apps you may already be internally planning on curating, therefore, saving time and money from having to develop them yourself. This would ultimately allow more development budget for critical features/integrations. To be clear, if HexOS were in wide release, I would completely agree with your planned phases. However, because this is still a beta, I think it would be advantageous for HexOS to foster community development sooner rather than later.
    1 point
  9. When you setup hexos, you are forced to wipe all data. There should be an advanced mode to keep as is. If ever your OS drive(say nvme) dies and the OS needs to be reinstalled, I don't want to lose all my data that's already setup in raidz xyz Forcing the user to wipe all drives is a disaster waiting to happen
    1 point
×
×
  • Create New...