Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Problems on the Desktop (2018)

itvision.altervista.org

Post reply on HN
Print view View original

321–330 of 402 posts

Re: Linux Problems on the Desktop (2018)

#321

Post by pjmlp »

curt15 wrote: post #308
pjmlp wrote: post #300

Earlier quoted context omitted.

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.

>Google's J++, not compatible with a large amount of random packages out from Maven Central. Google's implementation is derived from Apache Harmony. Is the same true for Apache Harmony?

Google's implementation was partially derived from Apache Harmony, nowadays it is partially derived from OpenJDK.

In neither case it is 100% compatible with fulll standard Java API and JVM bytecodes.

Partially is the keyword here.

Re: Linux Problems on the Desktop (2018)

#322

Post by rbanffy »

Tenoke wrote: post #304
rbanffy wrote: post #249

Earlier quoted context omitted.

> The Linux community has been in denial about this for years. That's not right. We all know support for some hardware is spotty and we all have learned to avoid that. My laptops tend to use Intel GPUs, for instance, because I want to work on them, not fix them. I'm eyeing that new Lenovo thingie with an epaper keyboard, but I know it'll run Windows and probably never be upgraded because nobody will write the drivers…

>Stop buying NVidia hardware. They actively sabotage Linux development. AMD is much better in that regard. Buy AMD instead. Sadly if you work with Deep Learning buying AMD is a surefire way to make most of the work published by others unusable without serious effort.

Is the number crunching side as terrible as the visualization side?

Re: Linux Problems on the Desktop (2018)

#323

Post by sandGorgon »

geezerjay wrote: post #186
sandGorgon wrote: post #183

> Create a universal packaging format for bundling software which supports signatures, weak dependencies, isolation (aka sandboxing/virtualization), clean uninstallation and standard APIs to make it possible to integrate an application with your DE. Well this battle is lost. There was always the RPM/DEB/PKGBUILD split. But rather than unifying the standards, we now have Flatpak vs Snap split. It is seriously frustrat…

It's not a political issue if you want to force distros to move their entire packaging infrastructure to a backward incompatible format that might still not be compatible with other distros because they ship specific versions of some packages which are in addittion packaged in a very particular way. Switching to RPM/DEB/PKGBUILD is not a simple problem, because the problem isn't really which packaging infrastructure…

But I'm not talking about that. I'm talking about TWO competing FUTURE formats that were invented to carry the battle forward.

Snap and Flatpak is already incompatible with what came before. They chose to not come to a a middle ground quite deliberately.

Re: Linux Problems on the Desktop (2018)

#324

Post by MivLives »

I use Linux, but only in a VM. Every year or two I try to install it on actual hardware. In the past ten years it has gotten so much better.

That said it is still not quite at the level I would use it as my main OS. If my laptop stops working when I'm away from my desk I really don't want to have to fix something broken. I need it to just work. And for all the many shortcomings of Windows it has been hammered on and written for a complete idiot to keep it just working a lot easier.

I will keep monitoring the situation of course and the second I feel comfortable enough will make the switch. Until then I'll just keep using a vm.

Re: Linux Problems on the Desktop (2018)

#325

Post by ilovecaching »

pjmlp wrote: post #299
coldtea wrote: post #236

Earlier quoted context omitted.

> 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.

> Amazon could rebuild AWS on top of hypervisors

Um, what?

> BSD or what have you and none of those users would notice

FaaS and CaaS doesn't negate that there is a kernel API you're interfacing with. It absolutely makes a difference. Claiming that kernels are completely interchangeable is extremely naive, but then again, your first statement about hypervisors is so absolutely, confusingly incorrect that it's difficult to take what you say seriously.

Re: Linux Problems on the Desktop (2018)

#326

Post by coldtea »

ilovecaching wrote: post #325
pjmlp wrote: post #299

Earlier quoted context omitted.

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.

> Amazon could rebuild AWS on top of hypervisors Um, what? > BSD or what have you and none of those users would notice FaaS and CaaS doesn't negate that there is a kernel API you're interfacing with. It absolutely makes a difference. Claiming that kernels are completely interchangeable is extremely naive, but then again, your first statement about hypervisors is so absolutely, confusingly incorrect that it's difficul…

Or, you know, it was a slip or a bad syntax, and you took the least charitable interpretation possible ("so absolutely, confusingly incorrect") and then took that to further extremes "that it's difficult to take what you say seriously".

>FaaS and CaaS doesn't negate that there is a kernel API you're interfacing with

Only in as much that it can't itself be emulated...

Re: Linux Problems on the Desktop (2018)

#327

Post by pjmlp »

ilovecaching wrote: post #325
pjmlp wrote: post #299

Earlier quoted context omitted.

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.

> Amazon could rebuild AWS on top of hypervisors Um, what? > BSD or what have you and none of those users would notice FaaS and CaaS doesn't negate that there is a kernel API you're interfacing with. It absolutely makes a difference. Claiming that kernels are completely interchangeable is extremely naive, but then again, your first statement about hypervisors is so absolutely, confusingly incorrect that it's difficul…

If you prefer the full description, type I hypervisors with unikernels.

Re: Linux Problems on the Desktop (2018)

#328

Post by fghtr »

killjoywashere wrote: post #251
fghtr wrote: post #230

Everyone for some reason expects that GNU/Linux should work on every hardware configuration. I don't understand that, honestly. Why is there no such requirement for MacOS? Why do Windows-certified hardware have to work flawlessly with GNU/Linux? Just buy a Desktop/Laptop certified for GNU/Linux and stop complaining.

Apple invalidates their own hardware, usually about 7-8 years after production. I’m sure Microsoft will too.

Does it mean that the developers of GNU/Linux must provide compatiblity with every piece of hardware in the world?

Re: Linux Problems on the Desktop (2018)

#329

Post by Mister_Snuggles »

magicalhippo wrote: post #35

I've been running KDE Neon on NUC for a while, and Kubuntu before that since KDE 3.5 days. But still it's not ready to become my primary desktop. The main issue for me is RDP-like (not VNC-like) remote desktop experience. Without that I'm not even gonna try. I mean the kind where I check my desktop before I leave for work, resume the session remotely from work (when compiling or whatever), and pick up when I get home…

This is another pain point for me.

I have one Windows machine and it doesn't have a monitor attached. All of my access to it is via RDP. It's actually incredible how well it works. Resizing the RDP window works as you'd expect, it automatically adapts when I connect from a HiDPI device vs a non-HiDPI device, it's fairly bandwidth-friendly, sharing local folders with the remote machine is easy and works well, etc.

VNC, even Apple's Screen Sharing implementation of it, is an incredibly poor substitute.

Re: Linux Problems on the Desktop (2018)

#330

Post by AnIdiotOnTheNet »

ordu wrote: post #319
AnIdiotOnTheNet wrote: post #145

Earlier quoted context omitted.

Nothing you're describing is a problem with the model, just the implementation. All of those things are easily solvable by being able to choose how the program sees the world. You can do it today with the various namespaces in Linux.

Yes, I agree. It is problem of implementation. But nevertheless it is a problem. I didn't tried namespaces myself, but I'm pretty sure that to do in in Linux it would be harder for me to get it to work. Even if I became familiar with namespaces. Multiuser model is settled, simple and transparent model, that just work. You have abstraction of user and abstraction of file access rights, and it is all that you need. nam…

> namespaces have no such a simple model. How can I run program from other user but give it some special rights to access this git-repo in my home directory?

In Linux terminology, launch the program in a new mount namespace with a rw-bind mount to your home directory. You can do this with firejail, bubblewrap, or minijail easily and without a config file.

Post reply on HN