Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "there is a desktop version too you know"
-
If Java versions can coexist on a system
If all java versions have their own packages on the AUR
If you can change envvars in a launch script and be sure that all processes of the application will persist your settings
Then why THE FUCK do package maintainers keep announcing to change the default java version to install their package, rather than explicitly doing that by themselves? Fuck off, do you really think yours is the only package that needs a specific Java version? Do you think each and every user will write their own init script, or edit the PKGBUILD to include the new version as an envvar in the desktop file? This is why Arch has a bad name, and they're fucking right. If you don't have the time to put a single motherfucking diff in the motherfucking pkgbuild to specify the java version in the desktop file, then don't fucking maintain the package. I know there are too few maintainers, but pretending to maintain a package while doing fuckall is much worse than leaving it unmaintained on the AUR so the first person who has time can pick it up.1 -
Watching posts with 'screenshots' taken from anything else but the 'PrtnScrn' button...undefined use the goddamn button! there is a desktop version too you know fucking horrible screenshots5
-
First time linux user feedback
Linux lovers are probably gonna eat me alive but I don't give a flying fuck
Maybe its a little lenghty or boring, tell me what you think
Backstory:
I work for game extension company. We work with WinAPI and such. I've been using Windows since forever and I'm happy with it. But I thought to myself "hey, if I wanna be a good dev, I should give Linux and OS X a try, too"
I downloaded Linux Mint couple of months ago to start with. I was unable to boot it from live CD no matter what I tried, even in recovery mode. Apparently, Mint 18.3 was based on Ubuntu 16.04 which doesnt support UEFI
Wait, what the fuck, all modern PCs have UEFI so what, do all Mint users have 10 y/o laptops and PCs???
Anyway, when I heard about Mint 19 being released I thought to give it another try and I did. What a surprise, it booted successfully from Live CD. I saw the Linux desktop for the first time in my life, yay! I then installed it, GRUB appeared, my Windows was still there and wasn't broken so I was happy SOMETHING was working. I configured timeshift and applied dvorak layout system-wide. Realised dvorak layout is fucked up big time and applied normal layout for just desktop environment. Everything was really nice until couple reboots later Cinnamon stopped launching (kept returning to login screen). Okay, lets use timeshift
First big what-the-fuck was when I found out system restore can only be done using GUI??? This is absolutely retarded and I couldn't believe it is true. Login screen has a reachable console but I can't login there since I can't type the password. Fuck, fuck, fucking drovak layout was there.
Recovery mode - I've spent 20 minutes trying to type "timeshift --restore" having to press all keyboard buttons just to progress with one button. I've had another what-the-fuck when I saw "error: can't restore timeshift - partition already mounted"
Okay, this is too much. Why the fuck would you bundle a recovery mode if you can't restore a snapshot from there.
I have spent 3 hours now googling and trying to remove this fucking keyboard layout. No dice. I am making another copy of the live CD now. I'm gonna reinstall the whole shit now. I have the desire to create a custom Mint version without this abomination of a keyboard layout.
It's okay. Windows has taught me to be patient.
Fuck Dvorak, I dont know who the guy is but his keyboard layout can eat my dick12 -
Hi there!
I've been worrying about the following problem for months now and I don't find any solution. Maybe anybody of you can lead me the way.
We are developing a software suite which consists of a number of desktop applications:
* 12 applications written in C++; all over 20 years old; further development by 5 or 6 guys (one man armys) - mainly bugfixing, changes of law implementations, small features
* 2 applications we are currently writing in C#; completely new developments of existing C++ applications; scrum teams with at least 5 guys; this is, where we put our focus in
These applications (C++ and C#) are sharing some core assemblies and are interacting with each other. So they are not independent.
We organize them in a mono repository in one huge solution, which consists currently of about 500 projects.
Advantages:
* With all projects in one solution and through project references, Visual Studio takes care of the right build order
* Code navigation is superb - every single line of code is accessible - this makes refactoring easy
* Every developer can map the branch and build the whole suite locally
* Debugging on the local machine is easy
* DevOps pipeline is straight forward - it just have to build a single solution
Disadvantages:
* The huge solution is extremely slow.
* If you want to build the solution or you want to debug (which does essentially the same as a pre step) Visual Studio is building a lot of projects, although they haven't been changed. Their detection is buggy. So sometimes you wait 2 minutes until it starts the app. That slows us down a lot.
* Full builds need about an hour, because its building the same projects (even if they haven't been changed) over and over again (with ready made nuget packages this could be improved a lot I think)
* If a core team member changes some core apis, he is changing the calling code too, although he doesn't know the calling code, because another team has written it. I don't think, that's best practice and it doesn't scale.
* Often, a C# developer has to mess around with C++ building problems, because the C++ projects are in the same solution
* It gets more and more confusing and frustrating, because there is no clear organizational seperation between apps and nobody can't just focus on his app alone.
Idea:
I was thinking about putting the whole framework and core projects in a new solution (around 100 projects). Then we could take all old C++ projects and put them also in a new solution (around 200 projects). This would leave the newer projects (new applications - C#) in the existing solution.
This should speed up things, and would be a first step to better seperation, BUT:
How should the integration process look like?
Scenario: Core team is changing an API in our framework
Current process: Because all projects are in the same solution, they change the calling code too. So it's immediately integrated and the app developers just have to do "get latest".
New process (?): Core team is providing the changes through a nuget package (new version). So does every developer now has to keep track of if there is a new package version and if yes, do the integration? And how can we coordinate the different teams, so they are upgrading all at the same time? Because we ship our applications as a suite, all apps has to use the same versions. Or should we automate the integration process? Is there a best practice?
I have to add, that our core team is making changes very frequently, so the integration process will have to happen often.
Any ideas/feedback/inspiration?
Thank you so much in advance!4