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

.NET on Linux – bye, Windows 10

piotrgankiewicz.com

Post reply on HN
Print view View original

151–160 of 290 posts

Re: .NET on Linux – bye, Windows 10

#151

Post by darklajid »

baldfat wrote: post #119
darklajid wrote: post #96

Earlier quoted context omitted.

I don't think that's their responsibility. Traditionally it's your distribution's job to create and provide packages. Arch Linux has one (I just installed it myself) and if we're talking rpm: Fedora has one as well, it seems [1]. So, what is upsetting you here, really? 1: https://admin.fedoraproject.org/pkgdb/packages/pinta%2A/

> Traditionally it's your distribution's job to create and provide packages That has not been true in my 15 years of Linux. Look at bitsync, rstudio, or other major programs. Arch Linux must build off of the source so that isn't a fair comparison you are on a totally different system (port). EDIT: Here is the one page of documentation to push out deba nd rpm on mono projects. http://www.mono-project.com/docs/getting-…

(For this discussion, Arch Linux is working exactly like Debian/Fedora/Suse etc. - installing binary packages.)

In my time with Linux using anything other than your distributions package tools is an exception and extremely rare. You might do that for - say - bitsync, because it is proprietary. Your distribution cannot use the same 'grab sources, compile against our current libraries and package it up' process.

pinta instead follows the normal process. You install it by using your package tools. Your distributions created binary packages for you already, hosted on their infrastructure.

Heck, even on Ubuntu you'd probably apt-get install pinta and get a different (Ubuntu provided) package instead.

Check http://www.gimp.org/downloads/ and see what they do if you want to download their software (they tell you that your distribution is in charge and even mention why that is usually a good idea).

PPAs and OBS offer ways to build packages, yes. But again, that's the exception - most of your packages aren't coming from there.

Re: .NET on Linux – bye, Windows 10

#152

Post by tychuz »

jameskegel wrote: post #60
tychuz wrote: post #44

Earlier quoted context omitted.

It's always not Linux' problem.

Can you clarify this statement?

Well, take any problem from a user regarding Linux - and it will not be Linux problem.

No hardware support? Not a Linux problem. Crappy drivers on Linux? Not a Linux problem. No Photoshop on Linux? Not a Linux problem.

Re: .NET on Linux – bye, Windows 10

#153

Post by tobz »

jorgeleo wrote: post #149

"Although the application did run correctly, it threw an exception that gdiplus.dll could not be found. It makes sense, that’s a Windows component so it’s not available on Linux. But my point here is that although being the .NET Core application it’d still crash, so imagine what would happen if I’d publish it to some Linux server – everything would seem to work, but actually it wouldn’t. Another point for the .NET Co…

It seems like he was happy that he was developing on Linux, because Linux is not the happy case for .NET. By doing so, he discovered a bug he might not have otherwise discovered until he was running his project on a Linux environment.

Re: .NET on Linux – bye, Windows 10

#154

Post by Vendan »

jorgeleo wrote: post #149

"Although the application did run correctly, it threw an exception that gdiplus.dll could not be found. It makes sense, that’s a Windows component so it’s not available on Linux. But my point here is that although being the .NET Core application it’d still crash, so imagine what would happen if I’d publish it to some Linux server – everything would seem to work, but actually it wouldn’t. Another point for the .NET Co…

I think the point is "develop on the platform you are going to use". You'd get that error when you were developing on linux, so it'd never make it to production. If you developed on windows, you'd never get the error, cause you have gdiplus.dll. Still you should be at least testing on something matching the target platform, but catching this kind of stuff early is a plus!

Re: .NET on Linux – bye, Windows 10

#155

Post by discreditable »

ygra wrote: post #73
CWuestefeld wrote: post #70

Earlier quoted context omitted.

Twice I've been bit by the unexpected updates during shutdown during a power failure . At home my UPS is only good for 5 minutes, so I want to shut down as soon as the power goes down. I do that, and Windows starts on "Installing 17 updates", with absolutely no way for me to intervene. And powering down in the middle of OS updates has to be about the worst possible time for it.

It will simply roll back the half-finished updates and retry the next shutdown. Those things are done transactional. Powering down won't hurt it.

> Powering down won't hurt it.

Usually. I see enough students who mess up their machines due to hard poweroffs during updates to say that sometimes it does not work out.

Re: .NET on Linux – bye, Windows 10

#156

Post by darklajid »

baldfat wrote: post #122
cosarara97 wrote: post #97

Earlier quoted context omitted.

It's packagers of RPM distros that should build RPMs. Upstream can't be expected to release packages for every distro (if any).

> Upstream can't be expected to release packages for every distro (if any). This isn't provide distro specific packages this is provide the one extra file over macOS and Windows. Also this is for the health of the Linux environment. That is why we have RPM and Deb they work for MANY distros and if your outside that then the source is there for aa build. One day appimage, flatpak or Snap will make this easier.

No, RPM and Deb files don't work for many distributions.

Yes, the formats are shared (say, RPM for Fedora, RedHat, Suse). But the resulting binaries aren't (usually, automatically - you might get lucky of course) compatible.

The whole point of distributions is to build a system. Fedora and Suse are on different schedules, make different decisions about updates, might run different versions of the libraries your package (here: pinta) depends upon.

Your RPM file often isn't even usable between different releases of the same distribution. So just adding a random RPM wouldn't make sense. You brought up OBS elsewhere: One of the major reasons that thing exists is so that you can build packages .. for a list of target platforms. OBS is a service that uses a build recipe and upstream sources (pintas tarball) to spit out binary packages for various different environments and formats.

So one additional RPM file wouldn't do the trick here.

Re: .NET on Linux – bye, Windows 10

#158

Post by witty_username »

hedora wrote: post #140
GrumpyYoungMan wrote: post #129

Earlier quoted context omitted.

> The real story here is the forced updates. How do people who are planning demos and presentations handle this? It's my worst nightmare. Manually run the update check every 2-3 days and run it again two hours before the presentation. Any updates that come out in that two hour window will allow you at least one delay. Come on, folks, this isn't exactly rocket science here. Keep your OS up to date and, surprisingly en…

It is seriously that bad now? You have to touch windows update three times a week?!? That sounds like an even bigger time sink than the whole "find a new Debian derivative because Unity breaks the alt key, and systemd breaks everything else" thing.

You don't need to switch distros to install other desktop environments. What did systemd break?

Re: .NET on Linux – bye, Windows 10

#159

Post by witty_username »

valarauca1 wrote: post #56
pjmlp wrote: post #54

Earlier quoted context omitted.

The OS is great, only macOS offers a similar OO ABI for the OS stack. Also I do have quite a few war stories from failed GNU/Linux updates, that eventually lead me to always keep /home on a separate partition and wipe everything else.

Keeping /home on its own disk is Unix101

I don't do that. What's the reasoning behind that?

Re: .NET on Linux – bye, Windows 10

#160

Post by witty_username »

cash3wz wrote: post #133
creshal wrote: post #105

Earlier quoted context omitted.

> What difference does that make? • It's more packages I need to download. Doubly annoying because 95% of the packages are just "thin wrapper around foo, because we're too hipster to use libraries directly like peasants ". • It installs system-wide services I have to disable/mask just so other programs don't mistakenly use them because they think I run KDE and they have to integrate into it. • Oh wait, I can't disabl…

I agree with you for point 2 & 3, I also hated installing KDE apps for this exact reason. But I can't agree on the first one. I have not checked what these exact thin wrappers are, but most of the time thin wrappers are really useful for testing and switching to another library without being tangled in the old one. It pretty much follow the "D" (Dependency inversion principle) in the S.O.L.I.D. principles: "Depend up…

I think https://en.wikipedia.org/wiki/Phonon_(software) is one such example.
Post reply on HN