An effort is being made to port the Maemo version of PSFreedom used to jailbreak PS3 consoles to Android. The original thread is on the Desire forum but since the Desire and Nexus One are almost one and the same it's prudent to post it here as well.
Maemo is almost purely debian based and we have the ability to boot ubuntu/debian on our phones using chroot so a port is very very feasible.
http://forum.xda-developers.com/attachment.php?attachmentid=394596&d=1283537643
The binary files for the N900 comprising a kernel module and two shell scripts
The original thread on the Desire forum
http://forum.xda-developers.com/showthread.php?t=772795&page=2
We can't let Maemo beat us
abc27 said:
An effort is being made to port the Maemo version of PSFreedom used to jailbreak PS3 consoles to Android. The original thread is on the Desire forum but since the Desire and Nexus One are almost one and the same it's prudent to post it here as well.
Maemo is almost purely debian based and we have the ability to boot ubuntu/debian on our phones using chroot so a port is very very feasible.
http://forum.xda-developers.com/attachment.php?attachmentid=394596&d=1283537643
The binary files for the N900 comprising a kernel module and two shell scripts
The original thread on the Desire forum
http://forum.xda-developers.com/showthread.php?t=772795&page=2
We can't let Maemo beat us
Click to expand...
Click to collapse
I'm with you, you have a pm
This is going to sound stupid but I'll ask anyway.
What will this do exactly when/if achieved?
jailbreak PS3 consoles = play backup games/homebrew
jailbreak PS3 consoles = play backup games/homebrew
htctouch1313 said:
jailbreak PS3 consoles = play backup games/homebrew
Click to expand...
Click to collapse
Can't we do that already with PSx4Droid?
PSX4Droid is a playstation 1 emulator. This is a jailbreak to force a playstation 3 in to debug mode to allow unsigned code to run.
As of yet we can't hope to begin as the source code is still unreleased until tomorrow.
abc27 said:
PSX4Droid is a playstation 1 emulator. This is a jailbreak to force a playstation 3 in to debug mode to allow unsigned code to run.
As of yet we can't hope to begin as the source code is still unreleased until tomorrow.
Click to expand...
Click to collapse
Oh, duh, I'm an idiot. PS3 lol. I was half paying attention apparently.
So how does this effect our Android phones though? I'm still confused I guess.
EDIT-
neoKushan said:
It's not the android phone that's being jailbroken, it's the Playstation 3 being jailbroken through the use of an Android phone.
Click to expand...
Click to collapse
I should have read first. My apologies.
So basically, our phone can be used to jailbreak our PS3's to run burned games?!?!
part of me wants this to happen and the other part doesn't. piracy ruin's the console companies and I'm quite happy that the ps3 wasn't hackable up until recently. it would be great to see homebrew and different os running on the ps3 instead of running pirated games. just my 2 cents
Piracy of ~20GB games is going to be pretty tiresome for most. Downloading 20GB on anything but an extremely fast broadband connection is going to be a no go.
Well I have a ps3 and I'm willing to test it out once it is ready for it. Its the original 60 gb. I've already had to repair the yellow light error twice so I'm willing to abuse it some more.
I'd love to emulate some oid my snes games on there.
Sent from my Nexus One using XDA App
source is out
The source has been released, Check it out and lets see if we can add another awesome feature to our device.
http://github.com/kakaroto/PSFreedom
Hopefully we can see a port soon
Bookmarking and watching this closely.
I have a new PS3 Slim so I'm willing to test too, so long as we know nothing crazy will happen LOL
I have an Xbox...don't care..but have fun with that!
Here's an extract from Kakaroto's blog:
Q: How much of the source is Nokia N900 specific? Are you using the Linux USB Gadgets library?
A: Very little is N900 specific, I’m using the include/linux/gadget.h if that’s what you mean. See next Q/A for more info.
Q: How hard is it to port it to a new device ?
A: Well, I’ve just separated my code from the N900 specific stuff, so it’s quite easy, there are mainly two functions to write, one to get and one to set the USB address.. two other functions that only return some static result depending on the configuration of the controller (the name of the endpoints, and whether the controller supports high speed or full speed mode). Read the README file provided with PSFreedom, and check the psfreedom_machine.c file for specifics on what to implement.
Q: How can I port it to a new device.
A: Well, first, you need to figure out what controller your device uses, in the case of the N900, it’s ‘musb’.. Then go to the driver code for that controller (probably in drivers/usb/gadget) and look for ‘SET_ADDRESS’. In the case of musb, it was in drivers/usb/musb/musb_gadget_ep0.c. In there it was setting the address to the USB device, so just copy that code into the psfreedom_machine.c to allow setting the address, and add a similar function to be able to retreive the address.
Then add a function to return 0 or 1 depending on whether the controller supports HIGH, FULL or LOW speed mode (go to usb_gadget_register_driver for your controller, and in the first lines, it should validate the speed argument, it will tell you which ones are acceptable), set LOW speed mode to return TRUE only if FULL speed isn’t available . Finally, add a function to return the endpoint names.. it will usually be something like ‘epXin’ and ‘epXout’ (where X is the endpoint number), or “epXin-bulk”, etc.. look at how the driver initializes its endpoints or grep for “->name” in the file to find where it sets it… That should be enough!
I opened a forum, only for it
here you are:
http://www.ps3underground.net/forum/viewtopic.php?f=13&t=6
I was just wondering about these PS3 hacks, once the USB devices is emulated and the code is installed (or whatever happens), does the PS3 still need to have the USB device attached in order to keep running the code? Or once it's hacked do you no longer need to have the USB device attached?
talz13 said:
I was just wondering about these PS3 hacks, once the USB devices is emulated and the code is installed (or whatever happens), does the PS3 still need to have the USB device attached in order to keep running the code? Or once it's hacked do you no longer need to have the USB device attached?
Click to expand...
Click to collapse
It's not permanent hack so you have to have the usb plugged in as long as you want play backup games.
houmles said:
It's not permanent hack so you have to have the usb plugged in as long as you want play backup games.
Click to expand...
Click to collapse
Well, technically you only need to have it plugged in at boot-time so it can inject the exploit payload and then you can unplug it. That is the case at least with the PSGroove exploit. Kakaroto has said he built PSFreedom mostly from scratch though, so I wonder if his exploit works in the same way. On the original PSJailbreak dongle (The one people were trying to sell in Australia for $150) they added code that would crash the system if you unplugged the dongle, but that has been removed in the opensourced versions
sassafras
you can disconnect one ps3 has booted up the exploit. have used this on my n900 on own ps3..does not need to be left connected!
Would be amazing if one of the talented devs on here could get this running. It's looking like progress in the desire forums!
Related
So in this thread it tells you how to install pc operating systems like windows and linux on the Evo 3D.
http://forum.xda-developers.com/showthread.php?t=1459153
This, is freaking awesome. This one is a big breakthrough.
----
Here is the thread in the Nook Color forums for ubuntu on the device:
http://forum.xda-developers.com/showthread.php?t=1055954
----
These two threads are native installs, not using some client to access the installation, the device itself is the client as it should be.
This is not some chrooted virtual OS simulation, but the real deal installed to the device.
----
In the back of my mind i've wanted to play with ubuntu installed on the MT4GS, but not a virtual installation I want it installed and running on the device natively.
I definitely don't have the time to do this and a lot i'm trying to do around here even if I wasn't in my busy season for work.
Dropping this information so I can find it later when I do get to trying to get ubuntu (and now windows XP looks like a possibility) installed on this device.
If anyone else feels like looking into this, here's a good place to start. If anyone comes across any other projects that are the real deal and not virtual installs please post links here.
Have fun!
Blue6IX said:
So in this thread it tells you how to install pc operating systems like windows and linux on the Evo 3D.
http://forum.xda-developers.com/showthread.php?t=1459153
This, is freaking awesome. This one is a big breakthrough.
----
Here is the thread in the Nook Color forums for ubuntu on the device:
http://forum.xda-developers.com/showthread.php?t=1055954
----
These two threads are native installs, not using some client to access the installation, the device itself is the client as it should be.
This is not some chrooted virtual OS simulation, but the real deal installed to the device.
----
In the back of my mind i've wanted to play with ubuntu installed on the MT4GS, but not a virtual installation I want it installed and running on the device natively.
I definitely don't have the time to do this and a lot i'm trying to do around here even if I wasn't in my busy season for work.
Dropping this information so I can find it later when I do get to trying to get ubuntu (and now windows XP looks like a possibility) installed on this device.
If anyone else feels like looking into this, here's a good place to start. If anyone comes across any other projects that are the real deal and not virtual installs please post links here.
Have fun!
Click to expand...
Click to collapse
Regardless of what impression you may have, it is ABSOLUTELY IMPOSSIBLE to run MSWin on ARM hardware natively. The reason for this is that MSWin is x86 and ARM is... ARM. The approach used in the first link is to use BOCHS (pronounced "Box"), which is a VIRTUAL HARDWARE EMULATOR. It requires a host operating system to be functioning in the background, in this case Linux.
As for Ubuntu... well sure. No problem. Its Linux and the phone runs Linux. Not that big of a stretch to replace the Android parts with GNU.
Note that NONE of this is any kind of "great breakthrough". Bochs has been around for a VERY long time. First OPEN SOURCED in early 2000. Yeah, 12 years ago. As for Ubuntu... well I suppose that the main reason that most people aren't making a native android replacement out of ubuntu, is that not many people are all that interested in it. Cute in theory, but not practical.
What would be a more worthy project would be to upgrade android to GNU libraries and utilities. This would afford us an actually USEFUL balance between the two. Also the ability to run X *through* android without having to do stupid things like VNC. Have the proper interface ***AS AN ANDROID APPLICATION***, leaving Android to work (i.e., phone calls, etc.) while simultaneously offering the standard Linux applications.
My thought though, is that this is becoming less and less important. Firefox is on Android now, the Document foundation has announced LibreOffice for Android -- supposed to be by late 2012 to early 2013... GIMP has no place on Android... That certainly covers the basics.
Appreciate the post. I didn't have time to dig into it too deeply, so took it at face value for the impression I got. Happened to come across it in passing and didn't want to lose track of something vital to the future dev of a project like this on the doubleshot. (but definitely this doesn't belong in the dev section at this time - just clutter there.)
I was hoping people would add to it, especially the way you have, who had more of an understanding of what's going on there - I didn't realize that it was a virtual environment for the windows stuff, but it did seem to good to be true.
Even if no one responded I figured the thread would get pushed down out of the way, but still be here when I got the time to come back to it.
----
My reason for running native linux on the device itself is to be able to use the Android SDK and tools without needing a computer to do so. I have 2 of these phones and a Nook Color. The NC has USB host support, so I could plug the doubleshot into it without frying either device. (yes, i'm blending android and linux concepts here - but usb host support in android shows that it's capable of doing it)
Even from one doubleshot to the other I could use wifi adb for a lot of stuff without plugging them into each other through USB and frying the phones. So that would be a victory as well.
The lack of a hardware charging circuit in the doubleshot makes the worry of frying the phones a big deal, power transfer through USB is a big hurdle to jump in management.
Beyond that - the doubleshot is powerful enough on hardware specs to be able to compile a kernel, but that's not gonna happen through a virtual linux install because the overhead is too much. A native install might just be able to do it though. Won't know until I try, but it's worth the work to get to the point of trying, even if it doesn't work out.
The Nook Color probably won't be able to compile a kernel - it's asking too much from a device not really able to handle that.
Getting what I mentioned above to work would mean I could do all my dev work with what fits in my pocket, and let me keep working wherever I am.
I do like the idea of an app to work with this through Android itself - but I don't see how I could use the SDk and variety of user-created tools without a native linux install. Worth pursuing either way though.
If anyone has anything to add, i'd be welcome to hear it. Just understand this is not a project i'm working on or actively pursuing right now - but fully intend to down the line.
Actually blue. There is a thread somewhere that has a step by step on installing ubuntu on gingerbread. I meant to add it when I added the backtrack link. For some reason I didn't, I probably forgot, I actually think the link for it is in the backtrack thread in the sticky.
If I do find it ill let you know.
Sent from my ICS Splashed using Tapatalk
Let me preface this by saying I already suggested this idea in the DEV POOL sticky of software development. Unfortunately that thread receives very little attention and my question would be better placed here.
Anyways: Currently WP7 has two emulators (at least that I know of) and they are for the NES and classic Gameboy. Unfortunately, we are missing some really great ones like Gameboy Advance (I still have all my Pokemon games from it), SNES, and N64. You may not be aware, but the Zune HD actually had a partially working Gameboy Advance emulator. The Zune HD possess far lower specs then new WP7 devices, even the first generation devices. The original iPhone 3GS can also emulate Gameboy Advance games and its specs are also a lot lower then current WP7 devices.
I'm curious as to why this hasn't been worked on (at least talked about). I understand that code could be a problem, but the Zune HD I'm sure had similar problems on a far lesser known platform with even less developers and still had some form of Gameboy Advance emulator. Also, native code of some kind is achievable now, correct?
Anyways, I'm just curious if anyone else would like to see this/know if something is in the works. If it is of any help, here is the link to the Zune HD Gameboy Advance emualtor; they even have the source code listed: http://code.google.com/p/visual-boy-zune/
Currently there are several issues with emulation on WP7.
1) The lack of hardware access (XNA)
2) Managed languages and the inability to remove excessive runtime safety checks (like bounds checking) makes it very hard to have efficient rendering and sound generation.
3) The lack of native code access and not allowing for unsafe code in managed languages
While technically you can run native code through COM, it would be a huge amount of work porting an existing emulator over that way and it would be limited to fully unlocked devices.
I do know a few people that has been toying with SNES or even GBA emulation for WP7, but in the end they've given up, because of the inability to have it running at any reasonable speed. Which is very understandable considering how slow it is to run an interpreted emulator inside an VM when u have no way remove safety checks or compile code on the fly.
I honestly don't see any of these things changing for WP7, considering how little to none extra API access that we've been given since the Mango SDK.
But looking at Windows 8 and the Metro style API's, Microsoft would be complete idiots to not bring the same set of languages (native/managed) c++/c# (with unsafe code!)/js to WP8 and native access to directx etc. So none of the WP7 issues would be present.
N64/PSX...that would require a whole set of even lower level hardware access.
So in short; The lack of native or unsafe code access is why u don't have a gba/snes emulator on wp7
Nudua said:
Currently there are several issues with emulation on WP7.
1) The lack of hardware access (XNA)
2) Managed languages and the inability to remove excessive runtime safety checks (like bounds checking) makes it very hard to have efficient rendering and sound generation.
3) The lack of native code access and not allowing for unsafe code in managed languages
While technically you can run native code through COM, it would be a huge amount of work porting an existing emulator over that way and it would be limited to fully unlocked devices.
I do know a few people that has been toying with SNES or even GBA emulation for WP7, but in the end they've given up, because of the inability to have it running at any reasonable speed. Which is very understandable considering how slow it is to run an interpreted emulator inside an VM when u have no way remove safety checks or compile code on the fly.
I honestly don't see any of these things changing for WP7, considering how little to none extra API access that we've been given since the Mango SDK.
But looking at Windows 8 and the Metro style API's, Microsoft would be complete idiots to not bring the same set of languages (native/managed) c++/c# (with unsafe code!)/js to WP8 and native access to directx etc. So none of the WP7 issues would be present.
N64/PSX...that would require a whole set of even lower level hardware access.
So in short; The lack of native or unsafe code access is why u don't have a gba/snes emulator on wp7
Click to expand...
Click to collapse
Well that is mighty unfortunate. I'm assuming the current emulators work because they don't need much power to run? Also is it XNA that allowed for the Zune HD to emulate the Gameboy Advance?
I thank you for your time in answering my question, hopefully Windows 8 will change this current situation.
ErikWithNoC said:
Well that is mighty unfortunate. I'm assuming the current emulators work because they don't need much power to run? Also is it XNA that allowed for the Zune HD to emulate the Gameboy Advance?
I thank you for your time in answering my question, hopefully Windows 8 will change this current situation.
Click to expand...
Click to collapse
I don't know much about the Zune HD, but from looking at the GBA project, it's using native code (OpenZDK?) and not XNA.
Current emulators work because most run at 20/30fps and the emulation of 8bit consoles is less demanding. Also most emulators are written in native languages, making it much harder to port over to WP7.
If WP8 is anything like W8 and Microsoft continues to allow emulators, I'm sure we'll see a lot of emulators for WP8.
The ZuneHD was never hacked at all. If I remember correctly (and I was big on the Zune scene), the Zune devices had far superior security software that was never cracked. Not saying it wouldn't have been possible if more people cared about development for the Zune (it had nowhere near as much following as iPhone and iPod).
Microsoft never gave out a full SDK for the Zune, only access to limited functions in XDA. There wasn't even support for 3D games...
But Zune fanatics were able to find a more "back door" method to hacking the Zune. They created OpenZDK, which allowed for more access to what the Zune can really do. It was almost like a partial hack (which you'd be used to if you're in the PSP hacking scene).
Through OpenZDK, you were able to develop software that better used the Zune's potential (that MS never tapped into). Developers could make 3D games, and even make an emulator. Now my ZuneHD crapped out on me before I could try the GBA emulator, but I used the crap out of it when it was just GB/GBC. I still prefer it over anything I've used on iOS and Android. The only downfalls were that you had to save the normal way, no fast forward, and no sound.
If Microsoft had given more freedom for developers in XNA, then they would have used that to make VBZ and it'd probably be easier to port to Windows Phone.
Microsoft just really messed up with the Zune.
whats the best open source GBA emulator? it would be interesting to use NFC and the Local Wireless to emulate Link functionality. I tried to port a GBA emulator to WP7 XNA but it failed, now with native code, i want to try it in metro.
No$GBA, but I'm not sure
Please try it to make a gba emulator for windowsphone
MaryJane420 said:
No$GBA, but I'm not sure
Please try it to make a gba emulator for windowsphone
Click to expand...
Click to collapse
I'm going to make one for windows 8 metro, then I can attempt to port it over.
I've attached the Windows RT binaries for NewWolf and EcWolf, both of which are Wolfenstein 3D ports.
NewWolf features OpenGL rendering, but does not have any sound support because the port uses a proprietary (ie: no source code) sound engine. To run NewWolf use the included batch file as there is an issue with 16bit color depth (the batch file will force 32bit).
more info -> http://newwolf.sourceforge.net/
EcWolf is straight up software rendered using SDL with full sound support and is very true to the original. Simply run ecwolf.exe.
more info -> http://maniacsvault.net/ecwolf/
I have also included the original Wolf3D 'demo' game files so people should be able to play this straight away. If anyone has concerns about this, let me know and I'll remove the game data.
These are also on the SVN repo, so feel free to pull it from there if you like.
Cheers!
The original game files were shareware I think, I dont think anyone can complain about you throwing in shareware files for an old game.
Nice work yet again. I was just about to ask if you had considered doom, but it seems you've already done it
Offtopic.
SixSixSevenSeven, i see you know a lot of about Windows RT and porting apps, and i have a Little question. I need a C Compiler for my Bachelor of Science Degree in Computer Engineering, and i don't have any laptop for running a C Compiler. I'v tried searching a C Compiler for Windows RT (I'v only seen a C# Compiler) and i want to know if will be possible to run something like gcc in Windows RT, saving money buying a laptop.
Thanks
comandospi said:
SixSixSevenSeven, i see you know a lot of about Windows RT and porting apps, and i have a Little question. I need a C Compiler for my Bachelor of Science Degree in Computer Engineering, and i don't have any laptop for running a C Compiler. I'v tried searching a C Compiler for Windows RT (I'v only seen a C# Compiler) and i want to know if will be possible to run something like gcc in Windows RT, saving money buying a laptop.
Thanks
Click to expand...
Click to collapse
Not yet. MinGW might run under the x86 emulator but anything it produces will also only run under the x86 emulator, and that emulator isnt 100% reliable and it is rather slow.
You would be best off with a laptop, sorry.
Also not really something to be discussed here.
SixSixSevenSeven said:
Not yet. MinGW might run under the x86 emulator but anything it produces will also only run under the x86 emulator, and that emulator isnt 100% reliable and it is rather slow.
You would be best off with a laptop, sorry.
Also not really something to be discussed here.
Click to expand...
Click to collapse
I tried MinGW under Win86Emu but the setup doesn't work properly. I found a Little C compiler (Tiny C Compiler) and works perfectly with Win86Emu (at least some simple code), so i think that this could save me temporarily from buying a laptop.
Sorry for asking about this here, but thanks so much for the Win86Emu idea
Already exists?
There is a Wolfenstein port in the Windows app store called Wolf.
Surface-RT said:
There is a Wolfenstein port in the Windows app store called Wolf.
Click to expand...
Click to collapse
Looks like it only has the 1st level based on the comments... a Demo of sorts I guess. These ports would allow you to play the complete game, assuming you have access to the game files. I have no idea if you could use the complete game files with this Store version.
I haven't actually tried either of these ports yet. But I am curious on whether they are an improvement over the original DOS game? I've played that a bit using DOSBox on my Surface...
domboy said:
Looks like it only has the 1st level based on the comments... a Demo of sorts I guess. These ports would allow you to play the complete game, assuming you have access to the game files. I have no idea if you could use the complete game files with this Store version.
I haven't actually tried either of these ports yet. But I am curious on whether they are an improvement over the original DOS game? I've played that a bit using DOSBox on my Surface...
Click to expand...
Click to collapse
This port is running natively, otherwise it is essentially the same as the dos version. But running natively means it requires less CPU power (no x86 + DOS emulation) which might help keep the tablet cooler and prolong battery.
Right now, here's what I have:
-Padtie, an open source "gamepad->keyboard" program, which runs on .NET 4, and hopefully should run on WinRT. I am going to test it after work today. It is open source as well, so maybe we can port if it doesn't "just run".
-DirectInput / dinput is not in WinRT, so I'll be looking into adding it. We won't be able to add direct support for the gamepads in windows store apps (like the emulators) because windows store apps can only support xinput (AKA xbox controllers). This is where Padtie will hopefully work it's magic, by making the emulator/game think that a keyboard is being used.
To the more saavy devs: IF Padtie works on RT, but dinput is needed, could I drop the dinput dll's into the same directory as the exe? What are your thoughts on doing so?
If people are interested in this task, please reply so I know how much pressure is on me to finish it . Well, besides the pressure I put on myself because I really want it.
Not exactly related, but still. I connected some gamepad (speedlink xeox) into my XPS10, it was recognized (it's visible in devices and printers), but when I right click it and select option to open gamepad control panel, nothing happens and even it has typical unknown file icon (seems that cpl is missing at all). Is it just a problem with my OS, or result of removing part of gamepad support by MS?
About DirectInput - there's no DI at all, or it is, but just metro apps can't use it? If it is somewhere, this should help:
https://code.google.com/p/x360ce/
This would be amazing as the PS4 controller pairs to the Surface over Bluetooth and is recognized as a Wireless controller however no game seems support it.
Very excited I found this thread, I was just about to create one on the very same topic!
Erisii,
I understand the desire to map to keyboard inputs, and it may even work for most things. However, I don't see how it would handle analog inputs, ie. joysticks.
I do not know enough about the driver side of things, but is it possible for a program to convert the generic input of a controller to the xinput you speak of?
Also, I have some coding experience, but am far from a pro. Let me know if I can help in any way, I have a surface RT running 8.1.
try rawinput
most hid joystick support rawinput
sample:http://www.codeproject.com/Articles/185522/Using-the-Raw-Input-API-to-Process-Joystick-Input
windowsrtc said:
try rawinput
most hid joystick support rawinput
sample:http://www.codeproject.com/Articles/185522/Using-the-Raw-Input-API-to-Process-Joystick-Input
Click to expand...
Click to collapse
I apologize for being a newb. I will look into this a bit, but I assume we would need to write some application that utilizes that? Or are you saying we should port it?
[email protected]
I just wonder if there is one.
When there is nothing is it possible to get the "oculus os/android" working on Qemu with kvm or something like that? Normal Android already runs on Qemu so is there a possibility?
Unfortunately not, as Oculus has not released the source code for the OS. We'd need that to compile it for Qemu's "Goldfish" target (ARM64 cannot run on x86_64, and vice versa, without tricks). Since we don't have any of that, not even a device tree, it cannot be done.
Android-x86 is a compiled version of the Android Open Source Project (AOSP) for x86/x86_64, so that version of Android is binary compatible with your PC and QEMU, normal ARM/ARM64 copies of android are not. We also cannot simply take the OS from the device and plant it into QEMU as, once again, they wouldn't be binary compatible and the OS on the Quest 2 wouldn't have the drivers needed to run on QEMU as it would only have the proprietary blobs needed to start the HMD.
Hmm, I was hoping for some kind of quest 2 Android SDK myself, so I could try out a few features myself, but it's not THAT important. Was kinda hoping I could test the OS and built-in apps a bit before buying it. Yes, I have a standing offer to borrow a friend's quest 2 for a few weeks, but it's honestly more work than it's worth, to do that, because he lives something like an hour away. If he was right next door then sure, but he's not. He also lives in a group home on a caddy waiver, so there's all these rules he has to follow which makes having friends over a pain, as I can only be outside or the garage, and not in their house.
There's so many things that I really would like to look at before purchasing one, just in the OS and settings, like how adding your own figures to the home environment for instance, and all the multi screen things that oculus seems to be adding. Not to mention that I'd also love to try out sideloading apps, which really almost requires prior knowledge as it's a bit different than normal sideloading I'm given to understand. All of this stuff is something I would love to try without having to potentially brick a working quest 2. And yes I know that nothing on a quest 2 should brick from any of that, but still, it's not a known entity to me, therefore the caution, to my mind at least, is worth it, considering if something happened I'd have a 400$ paperweight