current status
-
gentoo people try to flex on me like this but i would bet if a gentoo user would be faced with a week of compile errors nonstop they would probably quit using gentoo https://deacon.social/@ossobuffo/116434104017759862
@whitequark eh for single ebuild yes for complete setup it was 4days in 2007 for me and another 2 days for office and gimp
-
gentoo people try to flex on me like this but i would bet if a gentoo user would be faced with a week of compile errors nonstop they would probably quit using gentoo https://deacon.social/@ossobuffo/116434104017759862
@whitequark cannot confirm. am gentoo user, have been faced with a month of compile errors before
-
@whitequark cannot confirm. am gentoo user, have been faced with a month of compile errors before
@whitequark which tbf this was during my aarch64 + clang as default compiler + LTO default on + alternative linker + also the system is a graphical desktop not a headless system arc but you've got to do something for fun
-
@whitequark which tbf this was during my aarch64 + clang as default compiler + LTO default on + alternative linker + also the system is a graphical desktop not a headless system arc but you've got to do something for fun
@whitequark that system still runs to this day! even the kernel was clang-built for the bit
-
gentoo people try to flex on me like this but i would bet if a gentoo user would be faced with a week of compile errors nonstop they would probably quit using gentoo https://deacon.social/@ossobuffo/116434104017759862
@whitequark depends on who you ask. 15 yo me, trying to install Linux on a decommissioned hppa server (hp9000 d-class server), did certainly spent months watching compiles fail.
Edit: and yes, it just had to be gentoo. -
gentoo people try to flex on me like this but i would bet if a gentoo user would be faced with a week of compile errors nonstop they would probably quit using gentoo https://deacon.social/@ossobuffo/116434104017759862
When I started using FreeBSD, the way you installed anything was via the ports system, which was (and remains) a tree of build-system wrappers and patches for third-party programs. Often, non-trivial things would depend on a newer GCC than in the base system and it would do a full three-stage GCC build, which took hours.
All of this would be bad enough, but the ports tree was stored in CVS, and CVS did not support atomic commits. So every time you updated the ports tree, there was a chance you’d get an inconsistent snapshot. For example, the hash of the source tarball was stored in one file and the file URL in another, so they might mismatch. More often, you’d fail to get a new patch that fixed the build.
It was common to run a build for a few hours and have it fail, then run cvsup and have it work the next time. You could go and browse CVS on the web to see if relevant files were touched around the time you did the update, but just doing the update and trying again was usually better.
Oh, and occasionally things would be committed that were just broken and wouldn’t be caught until a Tinderbox build finished a couple of days later (especially common if one person updated an app and another person updated a library it depended on at about the same time).
I am very glad it isn’t like that anymore. I doubt I’d have the patience to deal with it.
-
R relay@relay.infosec.exchange shared this topic
