/tech/ - Technology

Look up Librewolf, have used if for over a year, will never revert

>>26805
ayy thanks

Isn't this why Basilisk (https://www.basilisk-browser.org/) and Palemoon (https://www.palemoon.org/) exist?

Mach and whatever hodgepodge of build systems chromium uses are such a pain, i never got them to work before. The only three browsers that ever successfully compiled were mothra, lynx and nyxt, and nyxt was tied to some heavy guix infrastructure that stopped working a few distro releases ago. This is the real cost of software complexity, randomly failing builds on my machine.

is there any specific reason why this is bad?

>>26811
>This is the real cost of software complexity, randomly failing builds on my machine
Your machine? Probably a lot more than that

>>26816
Less options = good?


In the absolute sea of shit Firefox is probably still the best. That or Librewolf. It irks me that I must keep a pet Chromium browser for the websites that are too shit to load in FF or are behind Cloudcancer

>>26817
options for features that dont exist anymore dont matter

>>26817
>Your machine? Probably a lot more than that
No we're the only ones, the unix programming environment is dead if not buried. Barely any user compiles software anymore. Nearly every new project gets away with using elaborate multi-step build systems, because apparently make is too hard. Prospective developers and package maintainers will already be invested enough in any project to bite the bullet. What the current sttate of javascript software can teach us is, that things can get complex very quick and we're in for a long ride. You might recall the tor project announcing in 2021 they will move to rust.

>>26819
Seems like modules, and build systems are something most programming languages completely fail to do in an intuitive and easy to use manner. It seems like whenever run into a major road block when programming it's something to do with one of these two things.

>>26840
C's preprocessor+linking approach works well enough with simple projects and few dependencies. For some languages robust build systems are a solved problem though, notably common lisp and ada. Common lisp has packages, so a build system only needs to load the relevant files, which is what asdf and quicklisp do. Ada has rock solid dependency resolution guided by include dirs and package name/file name identity. What truly elevates it from similar schemes like java's is gprbuild, which lets you set environment variables and select modules in an ada-like syntax.

All that is to say, the languages with the best build systems support packages as a language construct. Objects in java come close, but their more fine-grained nature make them impractical for managing dependencies.

>>26861
>C's preprocessor+linking approach works well enough
dunning-kruger moment

>>26862
>>C's preprocessor+linking approach works well enough
>>with simple projects and few dependencies
speedreader moment

>>26861
The C preprocessor is an amazing tool. They didn't make much better in 50 years in terms of multiplatform. Of course you can always abuse it and write it in an unclean way, but that's what a tool is.
Modules are really not obviously superior to the C way of doing stuff. There's tradeoffs.

Firefox is awesome!

>>26817
>Less options = good?
Have you looked at what's actually being removed? I checked some and they seem to be harmless.

>>26901
Admittedly no. I will eat the blame for that one.

>>26804
> Mozilla is removing dozens of about:config settings in every firefox update
Based

>>26819
> make is too hard
Pure make is terrible for anything that isn't a self contained C project. The only reason linux gets away with using it is because they have no deps and lots of manpower

>>26840
The only build system I know which isn't terrible is cargo
>>26861
Didn't java introduce modules a few versions ago?

>>26918
Autoconf is only as complicated as it is, because it's still using the 90s configure script paradigm. If you hardcode a lot of things, like pkgconf output, that are valid for every unix released after 2006, you will get a <20 line makefile for even moderately complex projects. That said for highly dynamic, modularized projects with many dependencies make is genuinely terrible.

>>26921
This. For years I avoided make from a combination of scaremongering and a lack of pressure. When I finally got to it I was surprised with how easy it is to actually implement and work with.
The sincere complaints seem to mostly come from professional (aka corporate) programmers who can't work with it in their environment. Something make was not designed for. This is the same attitude that proliferated jQuery and other such monstrosities.

>>26920
>The only build system I know which isn't terrible is cargo
cmake gets hate, but I don't understand why. scons is an abomination.

Just use XMake if you can

>>27021
Every Makefile or ninja recipe generated by cmake ties back into other cmake binaries or scripts. I have often had these builds fail in mysterious ways and with no discernable point where to start debugging. Then there is the compiler flag handling, which doesn't automatically pick up on your environment variables and can't be completely overridden at the configure or build stages, making static linking impossible in most cases.

Why are you bitching about build systems in the Firefox FUD thread?

>>26920
>cargo
How does cargo actually handle dynamic dependencies and config.h-style compile-time options? As far as i remember the build recipe was a literal markup file.
>>27023
For a second i thought you meant a discontinued make preprocessor previously used by X.org, but that's imake.
Flood detected; Post discarded