It does not help that this works beautifully on the Mac.
Is this not an annoyance to anyone else...and more importantly, considering all distros are now using libinput,can I compile my own libinput that will universally copy paste using win+c ?
61–70 of 384 posts
It does not help that this works beautifully on the Mac.
Is this not an annoyance to anyone else...and more importantly, considering all distros are now using libinput,can I compile my own libinput that will universally copy paste using win+c ?
Many of the driver problems come from the fact that Linux finally worked on the desktop about the time desktop machines were replaced by laptops. Desktops with slots tended to have relatively well-defined hardware, and plugging in third party hardware was normal. This is much less true for laptops. OS development for laptops requires that laptop. It needs a Q/A organization which has one of everything you support. Linux lacks that.
Microsoft got drivers under control with the Static Driver Verifier, which uses automatic formal proofs of correctness to determine whether a driver can crash the kernel. (The driver may not control the device correctly, but at least it won't blither over kernel memory or make a kernel API call with bogus parameters. So driver bugs just mean a device doesn't work, and you know which device and driver.) All signed Windows drivers since Windows 7 have passed that. This has eliminated most system crashes caused by drivers. Before that, more than half of Windows crashes were driver related. Linux has no comparable technology.
The monolithic Linux kernel is just too big. What is it now, 20,000,000 lines? There's no hope of debugging that. It shows.
I'm pretty high on the KDE koolaid, and contribute a lot to the project, and it is the most painful experience to know there is no actual answer to the question of what distro I should be recommending to people for a KDE experience. A sane KDE distro should be shipping these new updates after a testing period - all at once, preferably, I use Arch mainly but its release model also conflicts with KDEs since - for example - 5.5 came out developed against upstream Frameworks which eventually released weeks later as 5.17 (frameworks are released monthly), but 5.5 with 5.16 was broken as hell. Applications 15.12 came out weeks later after that, and were a seamless upgrade because they were also developed against the same Frameworks version, but they were already available and thus everything went swimmingly.
Fundamentally my point is that I imagine despite Fedora and Gnomes friendliness, the problem happens there too. It doesn't hurt that software availability on Fedora is awful and it is not presented at all as a consumer desktop since its more of a test bed for RHEL. Distros today are shipping around either fixed releases - that because of the fragmentation of the ecosystem nobody is targeting upstream - or around arbitrary goals, which can be years of waiting (cough, Suse, Fedora). But on the flipside an average user almost certainly does not want a fully rolling release like Arch, because breakage in Arch often doesn't stop a package from being pushed to release (and often those bugs are missed because Arch doesn't have enough users of testing to catch everything) and the constant churn means your system only works precariously in its current configuration - trying to roll back anything on Arch is insanely hard, because everything is built against the latest and greatest of everything else. Thus, there remains significant value in releasing updates at once.
What I really wish we had was Kubuntu, sponsored by Blue Systems, just with updated userspace software on a regular basis (feel free to freeze the LTS, or even have two repos at install - frozen or not) This problem is mentioned in the OP, but it can be soul crushing for a developer in this purgatory because your fixes and improvements may not see the light of day for almost a year or more.
Personally I'd love to see an Arch derivative (since it has IMO the least age rot and bloat of modern distros, cough Suse /etc/init.d after having systemd for years) that just did frozen monthly releases. You release, you wait two weeks, you freeze, you test, you release again all at once. Users get latest and greatest but you can also hold back anything broken until its unbroken. But that kind of commitment requires work, the kind of work you cannot just throw on hobbyists and hope gets done, the kind that needs salaries and business. I still wonder why there isn't any commercial presence of full stack computer vendors of Gnome / KDE - boutique vendors that ship distros running non-Ubuntu that then use their revenue to develop it.
That was a lot of typing, but just some anecdotal remarks:
Linux grsec is the greatest security project ever, and nobody supports it. Selinux / Apparmor / Tomoyo are all trash by comparison, and Arch's stock kernel doesn't even have MAC at all. It is also probably the greatest notch in Linux's belt over Windows that it can be objectively secure, when you actually care about security cough Wayland. There is a distro I see in my dreams that has secure packages, user repositories, and PAX enforcement to prevent malware from accessing anything but its own personal .config file and .share directory. Users can install their own packages rather than having to install them systemwide, but the package manager is smart enough to promote software installed by multiple users to a shared hierarchy rather than duplicating space usage. And the filesystem layout makes sense (/usr...).
xdg-app is supposed to be this pancea that saves the desktop from application fragmentation. It should give us sandboxing, appstream metadata dependencies so we don't need insane duplication of all the system libraries like in click packages, and a puppy. Lets see if that ever happens.
Audio will never get better. Just use pulseaudio and fix it where you can. I'm working on improving plasma-pa for KDE right now to make it more like the old Veromix widget (which was great). It already does its job of catching ALSA applications that would try to steal the soundcard, and rather than try to throw away all the work that went into it we just need to make it suck less.
Earlier quoted context omitted.
I've got a windows 10 machine with a pretty fast NVMe SSD. It takes 10 seconds to get to the login screen, and another three minutes to load up all of the services that are set to run on login. I'm convinced that the NTFS driver must be a nightmare of blocking I/O.
That's definitely not the norm. On both my Windows 10 machines the desktop becomes usable within seconds after login. Might be worth having a look at what's taking so long on your machine... As far as I remember there is even a Microsoft tool that highlights startup jobs that are slow to run, isn't there?
I've been using Linux on the desktop daily since about 1998. It may look a little prettier today, but I find it crashes and freezes a whole lot more these days.
Earlier quoted context omitted.
What would consider entry level? I use a Mac mini from 2012 (i7 with 8GB) every day and I'm not seeing any beach balls unless Flash crashes some web page.
http://www.apple.com/shop/buy-mac/mac-mini?product=MGEM2LL/A... Dont add any extras... its simply not usable on the net Hardware 1.4GHz Dual-Core Intel Core i5 (Turbo Boost up to 2.7GHz) 4GB 1600MHz LPDDR3 SDRAM 500GB Serial ATA Drive @ 5400 rpm Intel HD Graphics 5000 User's Guide (English) Accessory Kit
He's right. Many of the driver problems come from the fact that Linux finally worked on the desktop about the time desktop machines were replaced by laptops. Desktops with slots tended to have relatively well-defined hardware, and plugging in third party hardware was normal. This is much less true for laptops. OS development for laptops requires that laptop. It needs a Q/A organization which has one of everything you…
Or, am I correct in assuming that Linux has gotten so big and complex it'd be unreasonable to expect your average developer to be able to make a meaningful contribution?
I really enjoy using Linux, but I'll admit I still barely understand anything about it after using it for several years and it isn't from a lack of interest or trying.
#25 is wrong: > There are no antiviruses or similar software for Linux. Say, you want to install new software which is not included by your distro - currently there's no way to check if it's malicious or not. http://www.eset.com/int/home/products/antivirus-linux/
I have one more which this article doesn't mention: Bluetooth. It's an extremely fragile house of cards (as far as I can figure, there are a few kernel modules, dbus, a bluetooth daemon and pulseaudio involved) and every upgrade you roll is extremely risky. Currently my BT works but after a day or so uptime it will simply stop working and nothing short of reboot helps. (More https://bbs.archlinux.org/viewtopic.php?id…