Switched to Windows in 2018 because of Killer WiFi card not supported on Linux. First time after 10 years I was able to suspend my laptop without having to worry it will wake up in my bag and overheat.
Linux Problems on the Desktop (2018)
291–300 of 402 posts
Re: Linux Problems on the Desktop (2018)
#292Re: Linux Problems on the Desktop (2018)
#293Earlier quoted context omitted.
I've said for years that Linux works for grandmothers, and for me (and a bunch of others). It doesn't work for people who: - need a locally installed copy of MS Office or other Windows only software - IT admins that stopped learning a long time ago - etc As others point out, for som of us using Windows or Mac is a hassle. They're slow (30% longer compile cycles, don't even get me started on git), missing important cu…
how is git faster on linux?
Windows has abysmal performance in its equivalent of the VFS layer i.e. path handling, directory listings and so on.
Funnily enough the main reason is probably that compiling the Linux kernel is one of the most filesystem taxing workloads and also one of those kernel developers care most about.
Re: Linux Problems on the Desktop (2018)
#294Earlier quoted context omitted.
iOS and Android are non-windows OSes.
I'm sure you are aware that: * Android is technically linux, but typically smartphones are locked in. * All apple products are notoriously locked in.
I'm sure you are aware that:
- Linux is an implementation detail in Android, isn't exposed to userspace (not part of Java/NDK official APIs), Treble made it even less upstream like and who knows, it might even be replaced by Fuchsia's Zirkon
- Apple products being locked in doesn't have anything to do with laptops and 2-1 devices being the future desktops
Re: Linux Problems on the Desktop (2018)
#295Earlier quoted context omitted.
I'm guessing you're relatively tech savvy and enjoy troubleshooting (within reason). Most people aren't, of course.
I contest that many of us tech savvy folk still don't like Linux, and not just because it is different, but because it has significant problems that make it more of a headache for our workflows than other OSs. I wish that weren't the case. I'd love to be using an open OS, but Linux's ways of doing things doesn't mesh with how I work.
And then there are those of us that really can't work on a Windows machine because it just doesn't mesh with how we work. With Windows Subsystem for Linux I can finally at least get some work done on Windows but honestly it still feels like swimming with my arms tied behind my back.
Re: Linux Problems on the Desktop (2018)
#296> "most Windows 95 applications still run fine in Windows 10" Uhm, no. Not really. With hacks by the user (or OS) maybe, but if hacks are allowed then most of that list can be deleted.
The main issue you'll face on trying to run old 32bit Windows 95 applications on modern 64bit Windows 10 is that the installers often are 16bit and 64bit Windows do not support 16bit applications (which was actually technically possible, at least for protected mode 16bit applications which is the majority of them, as shown by Wine being able to run almost all 16bit programs under 64bit Linux).
Once you go past that hurdle though (and it is often very easy to do that since almost all of them tend to use InstallShield and there are workarounds for it... or in some cases, you can just copy the files manually :-P) the applications themselves tend to run just fine. For example here is Visual Studio 6 running on my Win10 machine (with a demo from DirectX 7 SDK) [0] - all i had to do was to edit an .ini file to disable the Java VM setup. Similarly here is Borland C++ 5 compiling my C engine [1] - BC5 works just fine (and i actually use it very often since it compiles the code instantly and offers an ok debugger). Outside of compilers, here is Wally [2], a texture editor/painter/manager for Quake, Quake 2 and similar games - the program is from around 1998 but works perfectly fine in Windows 10.
I use and run a lot of old applications for Windows and generally i almost never have issues getting them to work in Windows 10.
One notable exception is games (of which i also have A LOT of older titles) that have a combination of DirectX abuse and memory bugs that in 9x weren't noticed due to looser checking. My go-to solution is to drop dgVoodoo2's dlls in the game folder and run RTSS to limit the framerate at 60fps - this solves 99% of the issues.
Interestingly (but expectedly, considering the issues mentioned in the article) the situation is reversed with Linux. I tried recently to play several older game demos (i have around 30 of them) made for Linux around late 90s, early 2000s. Most of them worked fine (after installing a missing .so or two and an OSS-to-ALSA bridge), with the main exception being Shogo which relied on Gtk1 that i just couldn't figure out how to make work in Debian (which doesn't ship Gtk1 at all).
This last part is what reverses the situation for Linux: older applications relying on older versions of Gtk, Qt, etc just do not work at all and often you can't just grab the older .so files and drop them in, as they have big webs of dependencies that often go outside just libraries (like scripts, data files, etc). Which is also why i really dislike both Qt and Gtk - the former, being a C++ API, cannot guarantee a stable ABI even if they wanted to, while the latter being written in C could provide a stable ABI but the developers just don't care at all about stability.
Ironic that the most stable (API-wise) and backwards compatible desktop tech in Linux is Wine.
[0] https://i.imgur.com/Qz4GoJk.png [1] https://i.imgur.com/M6TXWFu.png [2] https://i.imgur.com/ggX9Ybq.png
Re: Linux Problems on the Desktop (2018)
#297>linux problems on the desktop
>Linux is administered by ssh
Right... on desktops, Windows is far worse with updates as far as breaking things goes. We have to deactivate the internet on Windows 10 machines so the updates don't break everything.
Microsoft do not care about breaking stuff with their updates at all. Ubuntu is the stellar opposite.
Re: Linux Problems on the Desktop (2018)
#298Earlier quoted context omitted.
how is git faster on linux?
Windows has abysmal performance in its equivalent of the VFS layer i.e. path handling, directory listings and so on. Funnily enough the main reason is probably that compiling the Linux kernel is one of the most filesystem taxing workloads and also one of those kernel developers care most about.
And it is worth mentioning if you've never used git on Linux, the difference versus Windows really is night and day.
Re: Linux Problems on the Desktop (2018)
#299Earlier quoted context omitted.
Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX. But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts. The DE has gotten much better transitively from all the work that’s…
> But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts. It "counts" for whom? It sure doesn't count for me as an end user who wants to run some bloody programs on my laptop. Also whether it's Linux or anything else on the phone it's totally irrelevant to the end users. The actual layers the users see…
And even as backend it is irrelevant for the large majority of cloud/serveless users using managed languages.
Amazon could rebuild AWS on top of hypervisors, BSD or what have you and none of those users would notice, unless they would be doing some native FFI.
Re: Linux Problems on the Desktop (2018)
#300Earlier quoted context omitted.
> Linux is literally the most used operating system on phone What makes this such a victory? The fact that Android uses a Linux kernel is totally meaningless to the overwhelming majority of Android users. The bootloaders on their phones are almost always locked down and even if that weren't the case, if their kernels were swapped out with something BSD derived how many people would actually notice? What is the object…
People saying "Linux won" because of Android would never say "Java won" which is every bit as true.
A large majority of Java developers wouldn't say "Java won" regarding Android, because it is in fact Google's J++, not compatible with a large amount of random packages out from Maven Central.