anything like this for Vue?
Bbbbbot
ReactOS Updates
131–140 of 142 posts
Re: ReactOS Updates
#132I really hope the integration with QubesOS[1] will be completed in the near future. It will allow to run suspicious legacy Windows software without any hassle. [1] https://github.com/QubesOS/qubes-issues/issues/2809
But would ReactOS be a best approach in this case?
I think that for the long term, Wine is a superior solution, as it can use all the nice modern features of Linux kernel, and can easily co-exist with modern aoftware. The only feature that ReactOS has and Wine does not is windows device drivers - and QusesOS does not need those.
Re: ReactOS Updates
#133Earlier quoted context omitted.
> Not that my hopes are very high in that regard, as Linux and the BSDs didn't manage to do that either, despite having most of the technology and even doing some half-hearted attempts (CORBA was a part of early GNOME)… D-BUS has taken up that role, but it doesn't get as much as COM/UWP, which many still don't realize that since XP the large majority of new Windows APIs are only available via COM, with a possible add…
DBUS would probably be closer to DCOM or even the Amiga's ARexx ports. Granted, with that plus XEmbed, you could get a lot of the benefits without an explicit object model/component system, but I haven't seen that done a lot in action. Linux users mostly go for 70s shell/pipes to cobble together parts. Better than nothing, but man, such wasted opportunities (and even something that doesn't require Lisp/Smalltalk/Ober…
KDE 2 was super scriptable through dcop, and also had embeddable UI compnents with KParts (or was that in 3?).
My first job after high school was QA for Lindows, and I used dcop to automate testing of their app store client (2002-2003).
Re: ReactOS Updates
#134Earlier quoted context omitted.
I agree 100%, but you can go further. Like, all the way: https://github.com/grassmunk/Chicago95
Just looking at it I'm struck by how difficult it is to get the small details right. I don't even know exactly what's wrong but the spacing at the top and bottom of the title bar text is visibly wrong, and the menu bar is too high? I don't say it to be needlessly negative, it just amazes me how difficult this stuff can be. And I don't think I could actually use this, it would drive me insane for reasons I can't reall…
Part of it appears to be that the font descender may have been used for alignment/padding, rather than the baseline. Agree though, when something is so burned into your psyche, tiny differences create a really aggravating uncanny valley effect.
Re: ReactOS Updates
#135What is ReactOS's endgame? It seems they will never have enough resources to become more popular than windows. And they will never manage to become the desktop OS of choice over Linux or Mac either. It seems to sit in an odd place with only a tiny userbase and no real goal, permanently playing catchup.
I think of it as a safety net. If Microsoft ever damages the reputation of Windows too much, ReactOS can act as a drop-in replacement for many things with relatively little investment compared to migrating to an OS on another kernel. Even if they're not currently a threat Windows, they have done enough of the groundwork that some extra funding and support could make them a serious competitor should the need ever aris…
> relatively little investment compared to migrating to an OS on another kernel
One of the more beautiful aspects of Windows is you actually rarely interact with the kernel at all. That portion of the OS could (and in practice often is) switched out and replaced without the user-facing portions being aware.
If you look at the list of NT system calls [0] you can see how frequently they've changed. The only programs that can safely talk to the kernel are core OS components, which in turn provide a user-facing stable ABI through the use of DLLs.
The fact Wine is running on a separate kernel is essentially 100% transparent to all but a handful of programs that intentionally poke the kernel, either for undocumented functionality or to e.g. detect tampering.
This is why IMO for running application software, Wine will always be superior. Linux is a really good kernel for almost everything, and with io_uring the last big deficit (async i/o) may be fixed.
ReactOS's remaining advantages are driver support for Win2k, and the whole explorer shell and start menu environment. If someone really wanted to, I bet you could run ReactOS's shell on top of Wine, fullscreened on Linux...
[0] https://j00ru.vexillium.org/syscalls/nt/32/
EDIT:
A thought I had after finishing this. Another benefit of ReactOS's architecture vs Wine is you could, in principle, directly copy at least some system-level DLLs/software from Windows (2000/XP) and get something akin to Windows 2003/XP running on a modern and up-to-date kernel, possibility with much newer hardware support.
I doubt the ReactOS devs themselves would want to get that close to even just binary blobs from Microsoft, but if it gets far enough along, I could see users scrapping together systems like this, maybe for retro games or something.
Re: ReactOS Updates
#136What is ReactOS's endgame? It seems they will never have enough resources to become more popular than windows. And they will never manage to become the desktop OS of choice over Linux or Mac either. It seems to sit in an odd place with only a tiny userbase and no real goal, permanently playing catchup.
I think there's a huge argument for a "controlled" Windows-compatible OS.
There are a lot of workflows dependent on software and devices that never had a proper update to support past Windows XP 32-bit.
Even if you use license-downgrade rights, it's going to get harder and harder to find the actual bits you need to keep such systems alive.
ReactOS could potentially provide that steady-state-- a perpetually available Windows XP, which is also recent enough that you could see new drivers added and software ported so you could still boot it on a commodity PC.
Re: ReactOS Updates
#137Earlier quoted context omitted.
You may have not realized but Windows has been in maintenance mode for a while, since v10. Aka the last Windows.
Windows has not been in maintenance mode and Windows 10 is not the last version of Windows: https://www.theverge.com/2021/1/4/22212817/microsoft-windows...
The amount of investment is down substantially, not even including the decimation of QA.
You'll have to do better than a new color scheme and fixing the dialogs they broke since Win7.
Now Windows terminal is something to talk about, but the number of devoted team members appears to be under 5.
Re: ReactOS Updates
#138I really hope the integration with QubesOS[1] will be completed in the near future. It will allow to run suspicious legacy Windows software without any hassle. [1] https://github.com/QubesOS/qubes-issues/issues/2809
Good idea— I’ve been loading windows but perhaps there’s no need. I liked the appVM and templates but Win10 must be hvm.... GitHub has a great scripted airgapped updated trimmed install:
https://github.com/elliotkillick/qvm-create-windows-qube
Re: ReactOS Updates
#139Earlier quoted context omitted.
> That's a pretty bold statement. I use computers for 10-20 hours each day. I've come up with some pretty bold opinions based on actually wanting to improve efficiency of using computers. Someone else's ideas of aesthetics almost always conflicts with efficiently using the computer.
You presented it as a fact, not an opinion, thus my original answer. FWIW, as a general rule, I disagree: say you get to use two pieces of software with the same functionality, shortcuts et. al. for similar amounts of time, the first having 0 regard towards UI/UX, and the second having spent some time thinking about how it presents information and overall legibility. I'd be more than extremely surprised if most users…
> FWIW, as a general rule, I disagree: say you get to use two pieces of software with the same functionality, shortcuts et. al. for similar amounts of time, the first having 0 regard towards UI/UX, and the second having spent some time thinking about how it presents information and overall legibility. I'd be more than extremely surprised if most users couldn't possibly end up being more efficient using the second.
The Windows 95 through 2000 UI, I think, expresses the second idea perfectly. Rather than being clunky like older versions, they had thought put into how the layout and presentation looked. Granted, some of its qualities stemmed from needing to be renderable on a 386 in reasonable time, it still achieved something both visually appealing and productive.
In contrast, whatever fad comes around to make buttons look like Play-Doh or glass or flat elements with no distinguishing features... they take away from it quite a lot.
Re: ReactOS Updates
#140Earlier quoted context omitted.
WINE and ReactOS are separate projects and the allegations in the Quora post are specific to ReactOS. WINE doesn't handle NT kernel internals; it reimplements public Windows APIs and proxies kernel functionality to the host userland (usually GNU+Linux+X11 but occasionally Darwin+AppKit). The main existential threat to WINE would be the Oracle/Google case being decided (sometime before June). If that winds up creating…
Let's do the reverse: call out BSD folks and sue everyone for using the C API + BSD networking.
BSD networking was distributed under a very permissive license, so that would extend to any new APIs included in BSD. You'd have to argue that the BSD license doesn't cover API rights, which would basically be like trying to argue that it's not really permissively licensed at all.
You'd probably have a better argument for GPL violation for non-GPL reimplementations, but I'm not aware of that many people doing proprietary reimplementations of Linux APIs. Hell, even Microsoft stopped trying that when they moved to WSL2.