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

Debian still having trouble with merged /usr

lwn.net

Post reply on HN
Print view View original

141–150 of 310 posts

Re: Debian still having trouble with merged /usr

#141

Post by 0des »

goodpoint wrote: post #115
rekoil wrote: post #33

Earlier quoted context omitted.

What killed Debian for me was when doing an upgrade of Apache and PHP it automatically restarted Apache temporarily without PHP configured, then the upgrade of PHP failed and left Apache running completely without PHP support for a while until someone noticed, and Apache happily kept serving .php files as text/plain during this time. A package manager should in my opinion leave daemon stopping/starting to the adminis…

You can disable automatic daemon restarting in Debian.

It specifically asks you too, but if you just next next next next through life you might miss it.

Also that behavior isn't unique to Debian at all.

Re: Debian still having trouble with merged /usr

#142

Post by rekoil »

goodpoint wrote: post #115
rekoil wrote: post #33

Earlier quoted context omitted.

What killed Debian for me was when doing an upgrade of Apache and PHP it automatically restarted Apache temporarily without PHP configured, then the upgrade of PHP failed and left Apache running completely without PHP support for a while until someone noticed, and Apache happily kept serving .php files as text/plain during this time. A package manager should in my opinion leave daemon stopping/starting to the adminis…

You can disable automatic daemon restarting in Debian.

Yes, and I'm sure you could in 2013 when this happened as well, but it comes enabled by default and I learned not to enable automatic upgrades on Debian derivatives instead.

These days we mostly deploy our stuff using containers anyway, and for my own personal machines I've just switched to Arch Linux since.

Re: Debian still having trouble with merged /usr

#143

Post by petre »

sph wrote: post #48
ssl232 wrote: post #39

Earlier quoted context omitted.

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

I am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project. A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have. In…

I find the role based FreeBSD core team approach more adapted to projects such as Debian. They also started with BDLF and then moved on to the core team approach. That's several BDFLs, every one of them with different responsibilities. It's 9 people in the case of FreeBSD. They've tried it with 20 people and then scaled back to 9:

"Deadwood and apathy in the 20-member core team lead to creating bylaws that set up a 9-member elected core team First elected core team in 2000 with few carryovers from old core team" [1]

It should also be an odd number if they vote, so that there won't be a tie in votes. The same approach is used in kendo and other Japanese martial arts examinations, the number of examinators is always an odd number.

This also solves the "what if the BDFL is hit by a bus" problem: another member is appointed.

1. https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolutio...

Re: Debian still having trouble with merged /usr

#144

Post by 0des »

Cloudef wrote: post #69
hyperman1 wrote: post #35

Earlier quoted context omitted.

From this comment, I assume you ran testing or unstable. Stable is great for letting up a server and let it run on its own for years without any maintenance (HN warning: No maintenance is of course never a good idea, but at least Debian made it possible) Testing ran in update conflicts at least once a month, but it was generally easy to resolve without bricking. Unstable, well, the name says it all.

No unstable, just regular release. Same story with ubuntu and friends. Ironically I've had better experience with rolling release distros.

Requesting you take cloud out of your name. We release you from the team. I regret to say we are going to have to provide you with a win11 laptop, and the authorities are on the way to claim the hardware you appear to be currently abusing.

Re: Debian still having trouble with merged /usr

#145

Post by scandox »

mwcampbell wrote: post #116
andrepd wrote: post #100

Earlier quoted context omitted.

"Poor businesses forced to build ramps and make their websites screenreader-accessible" seems a distinctly weird take to me. If we're no longer taking even the slightest bit of care towards looking after our fellow Man then it's not a world worth living to me. EDIT: It's also not just a "tiny minority", about 13% of the world's population have serious vision impairment. Making streets, businesses, services, products…

One can only be exposed to so much backlash from seemingly reasonable people before wondering if they're actually right.

People are not reasonable. They simply have their reasonable moments. If someone is angry because someone else asked for something then I think it's pretty obvious they're not in reasonable-mode.

Re: Debian still having trouble with merged /usr

#146

Post by WhyNotHugo »

egberts1 wrote: post #127

We can now kiss-gone the security for embedded world and its IoT-related security brethren. It is often the directory separation of /bin and /usr/bin that is used to denote the extent of firmware’s scope between these binaries that are require for a boot up and what are they require to support their applications. (Thanks, PDP-11). Such wonderful boundaries of IoT upgrade scope can and is often denoted as two-stage up…

Using `/usr/bin/` readonly is also a thing on some few distros (e.g.: Fedora Silverblue), so maybe you want to consider that for your usecase.

For device-local binaries (e.g.: not part of firmware), /usr/local/bin sounds like the right choice (also, somewhat in line what some BSDs do).

Re: Debian still having trouble with merged /usr

#147

Post by ssl232 »

jeffparsons wrote: post #120
ssl232 wrote: post #39

Earlier quoted context omitted.

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

I can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expe…

Guido van Rossum openly admits the move from 2 to 3 was a bit of a disaster. I think some of the decisions made since then have been more conservative in a bid to avoid such damage again. And talk of a Python 4 is for the most part academic.

It sounds like the package authors sticking with Python 2 that you're dealing with are just stubborn beyond belief. The rest of the world has moved on whether they agreed with the changes in Python 3 or not. Hopefully if the packages are useful enough to others and the licence allows it, people will fork them and make them work with 3.

Re: Debian still having trouble with merged /usr

#148

Post by WhyNotHugo »

iso1210 wrote: post #52

> The /usr merge idea was first raised in "The Case for the /usr Merge" by Lennart Poettering in 2012. It came out of the systemd community Well that's a recipe for a long drawnout battle

Yeah, ideas and projects are often dismissed due to coming from the systemd group.

For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

Re: Debian still having trouble with merged /usr

#149

Post by sph »

makomk wrote: post #97
sph wrote: post #7

Earlier quoted context omitted.

I'm quoting the article: "Debian took a more incremental approach, in part because it strives not to make wholesale changes to users' systems like those required by a flag-day upgrade to a merged /usr. In 2016, the ability to voluntarily switch to that scheme was added, then some attempts were made for newer versions of the distribution to be installed with a merged /usr by default. [...] The location of some files w…

Linux development in the present era is very heavily driven by Red Hat's needs and desires, and I don't think they have this problem because they don't support upgrading from one release to the next using the package manager - you have to reboot into the installer and do a kind of reinstall in place. So they can just require that all packages only have files in the non-symlinked directories after the flag day. Debian…

Red Hat is not only RHEL. Red Hat's Fedora supports distro upgrades and they didn't have much issues pulling it off. I was using Arch Linux when the merge happened and it was a non-event.

Re: Debian still having trouble with merged /usr

#150

Post by drexlspivey »

jeffparsons wrote: post #120
ssl232 wrote: post #39

Earlier quoted context omitted.

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

I can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expe…

Can you link to a few maintained packages that only support Python 2?
Post reply on HN