Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
| tomman |
Posted on 19-08-11, 18:53 in I still HATE smartdevices
|
|
Dinosaur
 Post: #481 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
What the hell has Australia to do with cellphones?! Don't tell me that they have to reverse the antennas down there so their phones can actually operate Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-13, 16:55 in N64 emulators vs. "PJ64 v1.x" emulators (revision 3)
|
|
Dinosaur
Post: #482 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Recently I've got into the wonderful world of Super Mario 64 ROM hacks - the scene has really moved forward since I first tried with "The Missing Stars" (the very first complete ROM hack, released a decade ago!). New items, bosses, and amazing courses that give a new breath of life to this 3D platformer pioneer. Heck, they even tried to fix the camera! Fast forward to the year 2019. Emudevs are now taking accuracy seriously. Mupen64plus is still progressing in this front (with the help of angrylion's RDP and the cxd4 RSP LLE plugins), and we now also have CEN64, whose goal is perfect LLE emulation (it's nowhere near yet, but MarathonMan's work is nothing short of impressive). And if you absolutely care about running your RAWMz on The Real Thing™, we now have very user friendly and (somewhat) affordable flashcarts (Everdrive 64 and 64drive), which leave the old Bung carts and clunky copiers eating dust. If you're a homebrew dev and/or ROM hacker, these are great times to be alive and kicking in the scene. But then, it seems that the SM64 ROM hacking community (which for some reason mostly congregates at SMW Central) didn't got the memo and refuse to leave their own ZSNES platform. Most hacks are developed for some pirate N64 knockoff known as "Project 64 v1.x", because they will not run on anything but that emulator. Not on real hardware, not on CEN64, and not even on Mupen64plus (mostly newer versions after the accuracy improvements, but a bunch of older hacks will not run on older, less accurate versions). Very few hacks are actually developed for the N64 - when you open the readme files that ship with hacks and find the chapter on how to setup Project64 to get their hacks to run, you know you're in for a rough time if you happen to be not on a x86 PC running Windows (remember: PJ64 is still Windows-only, even after its revival). ROM hackers usually blame the toolchain: most of the hacking tools of choice (like the famous SM64 Editor) are made by a sole individual that is known to not give importance to compatibility with anything that is not PJ64. In fact, "hardware compatibility" seems to be taboo on places like SMW Central (the usual excuse is something down the lines of "you're getting this for free, stop bitching, you self-entitled brat!", which is a double edged sword: it reminds you that ROM hacks are copyright-infriging works that come with ABSOLUTELY NO WARRANTY, but also means that you, the ROM hacker, are intentionally narrowing down your possible audience, which is not good if you actually want to improve your skills, for fun or profit). Impressive new hacks are still being released in this very 2019. For example, anything done by BroDute's Star Revenge series (from custom NPCs to Touhou-themed hacks, this guy does some seriously good hacks that deserve praise). Somari Dash (where the illegal stepchild of Sonic and Mario gas it up its way to victory - forget about Goombas and Thwomps), SM64 Openworld Quest (a remix of vanilla SM64 where you warp between worlds instead of using the castle for that, a common theme across SM64 hacks), Ztar Attack Rebooted (a well-balanced hack with plenty of new gimmicks, and that bastard "burn your ass 'till victory" Of all SM64 hacks I've tried so far, the only one that actually tries to target hardware is Super Mario and the Cursed Castles (another great hack I can recommend although the first King Boo boss is a PITA far bigger than the last Bowser course on vanilla SM64), and this one was just posted online a few weeks ago) - at least it's the only one that I managed to get running on CEN64 and a recently-built Mupen64plus 2.5.9 from Git (I'm sure there are other hacks out there that have little to no compatibility issues, but they're a tiny minority as of today, sadly). This also means that I now have to keep two separate Mupen64plus setups for gaming: - The latest shiny (complete with GLideN64 for best HLE video compatibility and looks) for commercial ROMs and properly coded homebrew/hacks. - An old, outdated, and buggy build, solely intended for emulating "PJ64 v1.x" ROMs. Right now I'm relying on Debian Stretch stock packages (v2.5.0) for the latter, but the day I take the warp pipe to Buster, most likely it means I'll have to figure out how to build an outdated emulator on a recent distro. Not my idea of fun. From reading old posts on the former bBoard incarnations, I can understand that the ZSNES "console" was (and still is?) a huge problem on the SMW hacking scene, and looks like the SM64 scene also has the same disease, with not much hope of improving in the short period (I can only hope that when the decompiling project ever gets finished, this gives ROM hackers and hacking tool authors a better understanding on how to better target the real thing, instead of sticking to a emulator that sooner than later will no longer work on PCs once MS drops the axe over Win32, except maybe through virtualization solutions that are usually ill-suited for most gaming workloads. Even PJ64 will have to get its shit together someday and start walking the road towards accuracy, if that doesn't have happened yet - I don't know as I'm not following that project due to its Windows-only nature). UPDATE: Oh, PJ64 is now opensource, and it's still alive, now at version 2.3.2 - For comparison, the Sonic ROM hacking scene didn't suffered of this at a large scale, because there has been no emulator monopoly in the last decade and a half. Sure, every now and then you will find a hack that crashes and burn on console (like the recent 32X hacks I reviewed on my 32X crashtest that will work on emulators but are known to not boot on hardware), but so far I've yet to see a hack that won't run on anything but Gens, for example. Hardware compatibility seems to be a given nowadays, and we have quite a few accuracy-focused emulators readily available (BlastEm, Genesis Plus, Exodus, even good ol' Kega Fusion was the gold standard of accuracy until the '10s). There has been no risks of monoculture in the Genesis/MegaDrive scene (or in the Sega scene in general, which basically restricts to the 16-bit generation as SMS/GG hacks are very rare, and Saturn/DC mods are virtually nonexistant considering the difficulties on emulating those two 32-bit platforms). Dunno why the Nintendo hacking scenes are very prone to this undesirable outcome (people turning broken emulators into platforms de facto) If anything, I've seen efforts of a couple individuals for "hacking the hacks" to improve compatibility, but this is only a band-aid at most (if the hack has used custom code additions, chances are it is unfixable by anybody but its original author) Preemptive answer: No sureanem, I am not going to emulate an emulator! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-14, 11:26 in N64 emulators vs. "PJ64 v1.x" emulators
|
|
Dinosaur
Post: #483 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Oh, it seems Debian Buster still has the ancient broken ROM friendly Mupen64Plus version I'm using currently on Stretch. But then, upstream didn't had released a new version until this year. 2.5.9 didn't made in time for Debian, but it's now on Experimental, if you're running Testing/Sid. I've heard that this "fuck the hardware" is only specific to the SM64 hacking scene, and it's less of a concern in other N64 game modding places (I've seen Goldeneye and Zelda cited) - how true is that? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-15, 11:28 in N64 emulators vs. "PJ64 v1.x" emulators (revision 2)
|
|
Dinosaur
Post: #484 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
In the case of SM64 hacks, from what I've been able to understand (I'm no N64 hacker, so feel free to expand/correct this), the two most usual pitfalls that cause hacks to not run on hardware (or less broken emulators) are the following: 1) Misaligned PI DMA transfers of MIO0 compressed data (that is, gamepak™ -> RDRAM): The real hardware requires PI DMA transfers to be byte aligned (2-byte aligned for cart, 8-byte aligned for RDRAM) - if your data is misaligned, the console will crash. Some retail games are specifically sensitive to this: if you check the pull request for Mupen64plus to fix DMA alignment, it improved compatibility with games such as Taz Express, at the cost of breaking nearly every single SM64 romhack because the developers of hacking tools neglected to obey a hardware restriction. Only those ROM hackers that have been careful to ensure proper ROM alignment of their MIO0 chunks (where the SM64 engine stores pretty much every single game asset, so you get a nice blank screen if the engine fails to load any of those) will actually stand a chance of getting their game to work on anything other than PJ64 1.x. 2) Invalid/malformed RCP commands: This one is on the video plugin (in the case of HLE emulators). Older plugins (like Jabo, Rice, and Glide64) were pretty much "anything goes as long as it can draw polygons to display". Modern HLE video plugins (GLideN64) and anything doing proper RCP/RSP LLE (Angrylion+cxd4, CEN64) are more strict, and will do exactly what the real hardware does: display garbage or nothing at all. This is also why even if you enable misaligned DMA transfers on recent PJ64 versions, you're still forced to use an older (and inaccurate/broken) video plugin. A possible fix here is to hexedit the ROM to replace the invalid commands with proper, well-formed commands (aka the "setcombiner trick"), and while this is enough to get some hacks working, you still have to deal with possible graphic issues later on. Oh, even if you fix that, you still gotta deal with hacks exceeding polygon limits too, which at best will slow dwon massively, and at worst will crash. The PJ64 guys are having a hard time trying to combat their own "ZNES" situation, unfortunately for them. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-15, 12:19 in I have yet to have never seen it all.
|
|
Dinosaur
Post: #485 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Touhou 17 roll call In order: - Rockstacker loli - Cow - Chicken (assume Hecatia is The Red Guy) - Miss Hakurei Dragon Maid® - Armadillo - Another dangerous goddess with too much clothing - Texas Aya YEEHAW!! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-15, 21:52 in Mozilla, *sigh*
|
|
Dinosaur
Post: #486 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Meanwhile, at the Seamonkey HQ: https://blog.seamonkey-project.org/2019/08/06/build-numero-deux/ The release train is back on the rails. GO TEAM! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-16, 16:01 in Board feature requests/suggestions
|
|
Dinosaur
Post: #487 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
I... didn't noticed. But then, I'm on Seamonkey, a browser where the obsession is not at the security theatre, but actually getting the next version released. BTW: the random page load delays are still there, particularly at the Discussion board. And since I'm now forced to read this From My Cellphone™ thanks to our benevolent phone and ISP company, it gets incredibly confusing (is the delay caused by the site? by our shittyass 3G/4G networks?) Not that I care anymore, but I guess a bug is still a bug? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-16, 16:48 in I have yet to have never seen it all.
|
|
Dinosaur
Post: #488 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by Kawa Even better: she is not just another bird tengu, but a horse. With wings. Saki's theme song is "Prince Shoutoku's Pegasus ~ Dark Pegasus". The cowboy ZUNhat is not a fandom addition, it's actually canon - guess that after reading that chapter of Japanese history/folklore, ZUN went and Mayan/Aztec 2hus fucking when, ZUN?! You already touched Greek mythology with LoLK, why not fully cross the Atlantic this time? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-18, 17:44 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #489 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Moving on with the Stretch->Buster, one computer at a time: today is the turn for the Dell laptop. MATE is already FUBAR since the GTK3 infestation, and I don't really care anymore, so why keep postponing the upgrade? Let's do it, computers are broken forever, and me living with broken things are the way of life. Communism, etc. Right now, I'll have to read a kilometric changelog (I'll need to reindex my non-existing PostgreSQL 10 databases for reasons, as the very first checklist item) The very broken Steamlaptop™? That will be for last - I'm very lucky my patchy DSL held for long enough to let me download ~3.5GiB of updates on the Dell in 6 hours! No hurry on this one. I spent some time checking stuff on my IBM TV box (after dealing with yet more boot issues thanks to the remnants of the fried TV tuner/capture card, and the SB Live! that usually decides to shit all over the PCI bus once in a while). Surprise: HW video decoding now works! Without crashing the box, even!. And no invoking the next tier of ATi driver hell, either!!! (I don't miss "radeon: the kernel rejected CS", followed by the GPU assploding its guts all over whatever it's plugged into the DVI port) The good: - 720p is fairly stable, CPU load is minimal, as expected. - I can actually play another video AFTER playing the first one, without having the kernel to enter Lunatic Mode. The bad: - It only works in mpv, and only when using --vo=vaapi --hwdec=vaapi (--vo=gpu causes some weird GL error, falling back to slowass software decoding). VLC is hopeless, and on anything not using proprietary blobs, VDPAU is emulated trhough some compatibility layer over GL/VAAPI that it's slowass as hell and still falls back to softdec anyway, so it isn't worth using. - 1080p or 60FPS sources are too much for this HD2600 first-gen UVD failblock. The ugly: - I got random A/V desyncs due to unknown reasons! Sometimes I get "[ao/alsa] ALSA XRUN hit, attempting to recover...", followed by MASSIVE frame dropping while the video stream tries to catch with the audio stream. Mind you - this is not constant: testing with the same clip yields very different results during successive runs (sometimes it will not drop until the very end, other times it will drop like mad ass crazy). Messing with audio buffer sizes is of no help. Switching audio output drivers don't seem to help: I don't run Pulse on this thing, SDL is more or less the same hell, and with sndio I've get the best results so far, with a couple frames dropped every now and then... but not always. Debian's mpv is not built against OpenAL, so I guess I'll build my own and try. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-18, 21:47 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #490 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Upgrade done. Reboot went smoothly (aside of a boot hang, but that's due to this junky ATi videocard on this Dell - the last replacement I bought tends to hang at early KMS or BSOD under Windows every now and then. Yay broken shit~). They changed DejaVu Sans, the default font. I had to lower the default size to 9. Looks... weird, but I guess it's just matter to get used to it. After the reboot, Qt5 apps were crashing at start. Turns out I had to rebuild my Qt5-GTK2 style lib, as the Qt libs minor version were mismatching. Fortunately qt5ct (the "misssing" Qt control panel for Qt5) is now on the Debian repos starting with Buster. Oh, I also lost my sound card this time too - Pulseaudio was claiming that there are no soundcards available! Blame God bless the Arch Linux wiki - I've never used Arch and have no plans to try it anytime soon, but its wiki keeps saving my ass over and over and over - it's mostly distro-agnostic, which is absolutely great. It should became THE Linux manual, PERIOD. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-19, 02:31 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 1)
|
|
Dinosaur
Post: #491 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Got UVD/hwaccel working on this fine PoS... sort of. First, some background on my previous experiments, courtesy of ye olde bBoard of yesterday: https://helmet.kafuka.org/byuubackup2/viewtopic.php@f=6&t=1265.html Long short story: I can't have UVD and DPM working together due to a longstanding kernel bug with those two bits on R600 GPUs. Power saving is nice (it helps protecting hardware from cooking itself), but since noone gave a fuck on R600 and opensource drives (another case of "too little, too late"), it means you have to turn off DPM (it's actually off by default for R600 GPUs) if you actually want to use the HW video decoding features you've paid good money for a decade ago. On the flip side, I can actually play 1080p flawlessly without upsetting the kernel, yay me~! I only have to rebuild my initramfs and reboot each time I want to choose between watching anime OR doing anything else while protecting my videocard. Good for me that I still have plenty of spare fans and thermal paste! ...and it only took those Lunix ATi/AMD folks like 10 years to get there! Year of the Linux Desktop™® anyone? tl;dr: want the AGP retrobox of your dreams? Get an HD46x0, forget that everything else ever existed. And upgrade to the latest Debian stable for your own sanity, at the very least! Oh, don't forget to add -N to your ls alias definition on your .bashrc, otherwise you will get those annoying quotes wrapping any filename with spaces (because that's a Windows-ism that must die, nevermind that the Real World goes beyond Unicrud and its collection of space characters). Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 12:52 in I still HATE smartdevices
|
|
Dinosaur
Post: #492 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
My fate is sealed: from now on, I'll have to coexist with broken devices every single day of my communist life. My routerbox is dying, it seems: first a HDD crapped out last weekend, and now, we're back to constant segfaults and kernel panics every time something resembling a CPU load happens. Yay me. Allcrapper is once again doing what it's best for: crapping its pants with endless bootloops. Reinstalling stuff (like the Googlebits) is next to impossible when you don't have a working DSL. BUT! Turns out I never needed Kingo Bloat to root this crap: this thing was already half-rooted from factory (at least in the ROMs I've been using). You only need to follow that XDA guide to check where you should place every relevant file, and ignore the "delete Kingo" part: --- Common files --- Don't forget to remount /system readwrite first! No need to get "su" first - you're already root on the console (check with "id"), it's only the system partition that ships without the remaining required bits so your crapps can join the party. After doing that, reboot, open SuperSU, let it finish the work, reboot again, done. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 18:27 in Computer Hardware News
|
|
Dinosaur
Post: #493 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
It's not the first time nVidia ends the party for us users of their older hardware. Remember when Fermi GPUs were in the roadmap for Vulkan support (the hardware itself supports it just fine, from what I've heard), then suddenly "MAXWELL+ ONLY, SORRY". And then there is the whole trainwreck of Their hardware support lifecycle is still amazing, with regards of driver releases. But once your hardware is on the edge of getting moved to the legacy branch in the next 3 years, you know which company whose hardware NOT buy on your next refresh cycle. Oh wait, this means noone should buy GPUs at all :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 19:06 in Computer Hardware News (revision 1)
|
|
Dinosaur
Post: #494 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Posted by Nicholas Steel ...which means exactly nothing for those of us either Not Running Windows®, or actually wanting multiplatform solutions (of which Vulkan is one that will actually work everywhere but Macs). I guess the only hope for us Linux users to get Vulkan on our Fermi GPUs are when the Nouveau folks actually implement it (but then, they're focused on recent hardware too - they get no help from nVidia so they have to gather their reduced manpower around the most attractive target, which means that anyone using 5yo tech gets nothing...) Anyway, while engineers make the silicon and write the drivers, the marketing (and sometimes Legal) guys are the ones that greenlight actual releases. If not adding a single, niche feature helps them selling another thousand new GPUs even when the engineering costs are already covered for supporting it on previous-gen hardware, they'll keep doing it so. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 21:38 in Computer Hardware News
|
|
Dinosaur
Post: #495 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
IBM is opensourcing the POWER ISA: https://news.slashdot.org/story/19/08/20/197244/ibm-is-moving-openpower-foundation-to-the-linux-foundation IBM should have done this at least two decades ago, when PPC was still relevant! But hey, some competition for RISC-V is always welcome. "ARM everywhere" is not the direction I want to take, despite the need to dethrone x86 for good. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 22:35 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 5)
|
|
Dinosaur
Post: #496 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
VirtualBox missed the Buster release (just like it happened on Stretch, due to some silly Orrible® So this means my final Stretch->Buster update (my Steamlaptop) will get even more delayed. Time to wonder why. UPDATE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466 Oh boy, it's the same fucking bullshite that happened prior to Stretch too! Even worse: its release to buster-backports (when that repo actually starts getting packages) is in doubt due to some political crap between Orrible and Debian maintainers. I don't want to have to build my own .debs from the Sid sources, or even worse, use the upstream ones. Guys, how do I get someone to shit a smelly turd on Larry's precious and very expensive boats!? UPDATE 2: Tried building .debs from the Sid sources. It wants me to install nearly three quarters of a gigabyte of shit, including a new JDK (OK, I'll have to install that anyway as JDK8 is pretty much dead except for enterprisey, but still... why in the hell do I need a JDK to build a native VM!? This isn't Android, y'know)... and texlive-fonts-extra, which on itself is about HALF A GIGABYTE OF GOD ONLY KNOWS WHY. (actually 414MB) On a single package, no less! So... that's just NOT happening, Orrible. Unfortunately, I do need VirtualBox for work reasons. I guess I'll have to gamble my luck with the Sid binary packages, taking advantage that we're still not very far away from the Buster release and therefore there should not be compatibilty troubles, considering that the next Testing is still thawing. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-20, 22:53 in Cartoons, imported (revision 2)
|
|
Dinosaur
Post: #497 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Your next Evangelion is going to be FOSS powered - Khara is switching to Blender for future projects: https://entertainment.slashdot.org/story/19/08/16/2113234/anime-studio-khara-is-planning-to-use-open-source-blender-software https://www.animenewsnetwork.com/news/2019-08-18/khara-to-completely-switch-to-blender-open-source-3d-software-after-evangelion-3.0-1.0/.150173 Apparently even all the Evangelion cash cow funds are not enough to cover the new 3DS Max (They still seem have a plan C for when Blender is not enough, and that's... Unity?! Yes, Unity, the game engine - you can now make cartoons with it too) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-21, 13:02 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #498 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
My experience with VMs was originally with Virtual PC, then VMWare Player, and finally, VirtualBox, with a brief stint at Hyper-V. There is OVF which is supposed to be a interoperable format to easily move "appliances" between virtualization solutions, but in practice it has largely failed. I once tried to export a VBox VM to Hy-perv. "Easy enough", they said. Nope, you simply don't even have to try. Unless you're masochist. Like me. IIRC I also remember having moved my licensed XP Mode VM twice: first from VPC to VMWare Player (it involved jumping some flaming hoops around the VMWare site to download a converter tool, then yet more hoops to get it installed and the VM eventually moved). The second move was from VMWare to VirtualBox, but in this case I just cheated and copied the HDD image - that's the most safe way to do it, actually! (that, and using a hacked VBox BIOS image to "inject" the XP Mode OEM activation sauce). So yeah, "interoperability" is a curse word of sorts here. But I agree that someone should fork off VBox (and not just sent to the Apache House of Unloved Orrible FOSS Projects, where software comes to die) for the good of the project, as its future under Oracle is anything but brilliant. Reminds me of another longstanding VBox bug involving 3D acceleration and nVidia GPUs under Linux with the proprietary blob (which makes running Windows 8.x/10 or W7+Aero pretty much impossible), a intentional regression that Oracle was refusing to fix just to please a single customer (don't have the bug number at the moment, and dunno what happened with it). It would be a shame to see VBox die, as that's by far the most user-friendly solution out there - VMWare left their desktop solutions to rot, and QEMU/libvirt are not exactly for the faint of heart - VirtualBox is the "just works™" solution for those of us who still have to virtualize some XP junk every now and then, or for toying with multiple OS on the desktop (VMWare Player used to be great in the past, as long as you only had the need to have a SINGLE VM per host, unless you were willing to fork some good dough for a Workstation license) --- Anyway, I'm glad to know that the Sid packages of VirtualBox (now at version 6!) do indeed work in Buster. You however need to install libvpx6 (once again, who comes up with those ridiculous unrelated dependencies!?), which is not in Buster, but the Sid package is compatible. I really don't like to "break Debian", but I HOPE that their Debian maintainers will get their shit sorted out eventually and push the packages to Backports, allowing me to stick to the stock repos. I don't really care about security updates on this one: while I actually do run VirtualBox on production servers (or used to do at my former job), none of those setups are hooked up to the shark-infested Wide Open Web where Lil' Skript Kiddy can attack the emulated NIC or something. The rest of my use cases for VBox are at home, where a VM will rarely run for over a couple hours at most. But then I guess Orrible beancounters and Debian packagers know better than me :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-21, 17:41 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs) (revision 1)
|
|
Dinosaur
Post: #499 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
Bring me a nice foolproof GUI (like the one VBox has), and decent 3D acceleration that doesn't require me to buy a second videocard and play PCI pass-through shenanigans, and I'll reconsider. But then, that will eventually happen if Oracle continues alienating its userbase. VMWare is quite irrelevant on desktop nowadays (not to mention that it's closed source and not free), and Hy-perv is Windows-only (and useless for desktop, to boot). Either libvirt/QEMU gets user-friendly enough to reach "appliance" status (the one that VBox has today), or VBox gets forked (I guess that it will unleash the wrath of Larry, but whatever) Regarding that nVidia flickering bug, I found the ticket: https://www.virtualbox.org/ticket/13653 A 4 year old regression introduced to fix something for some unnamed paying customer by some developer that eventually left Oracle. Fixes were initially rejected, then the usual "it's Open Source, patches welcome!", then some bikeshedding, and eventually a compromise: not a checkbox, but an environment variable. Except that the bug somehow ended hitting Windows users too, where setting environment vars is NOT a walk in the park because lolMicrosoft. And it seems that the bug was reintroduced on the latest Vbox 6.0.x, without hopes for a solution because it somehow only affects users on nVidia hardware using the blob. So yeah, endure ATi driver hell, Intel is Good Enough, or if you're lucky to own one of the 3 GPUs with half-decent Nouveau support, uninstall the blob. All of this for having a shiny desktop (or in the case of W8/10, a desktop at all, thanks to forced DWM) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-08-21, 19:27 in (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
|
|
Dinosaur
Post: #500 of 1318 Since: 10-30-18 Last post: 9 days Last view: 3 hours |
https://wiki.debian.org/VirtualBoxInstallation of non-free edition Well, fuck you Debian, and FUCK YOU VERY MUCH, ORRIBLE. So yeah, VirtualBox is pretty much done on Debian, partly because their maintainers can't make a goddamned exception to their absurdly rigid "no new versions from upstream on Stable, even if upstream have separate maintenance branches" (remember the whole Iceweasel fiasco), but mostly because Orrible doesn't want anyone using their products without paying them dearly, because Larry wants to buy another boat. Build my own .debs it is, because I really can afford wasting 3GB of disk for a single program I use every now and then. Also, fuck you One Raging Asshole Called Larry Elison. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
