Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

mostly in the logging, it's hard to get anything truly meaningful when shit hits the fan, I even studied the man pages fairly religiously but because the native application had it's own logging mechanism which was removed by the distro maintainer/packager (fedora) it took a while to realise and reenable. this is the first listed not because it's a big deal but it cost me a day of work, which is hard to explain to my boss.

There are multiple issues in how it handles networking, notably that 802.3a/d bonding is kinda broken and nobody seems to give a crap, which means using it in production is somewhat dangerous for me, the same way that loading modules breaks, gets fixed then rebreaks in odd ways (lsmod/modprobe)

the fact that nobody seems to give a crap about the previous bug, and that bugs get introduced and the developers hostile attitude also rubs me wrong.

FirewallD is a shitshow, and yes it can be disabled, but that doesn't mean that it's -not- going to be the officially supported method of interfacing with netfilter in the kernel.

I've had systems become unbootable because systemd introduced a bug which caused it to segfault and I couldn't "revert" the change like I would with a bad kernel, but this is the cloud era and I should really be adopting ephemeral builds- but if it ever happened on a stageful machine I'd be angry, I can HA all I want but I want to be able to recover and more robustness is significantly better than less.

My problems are fewer because I never wanted to touch systemd, I've been skeptical and rewarded somewhat for my skepticism when i actually started using it out of curiosity or because I really hate being on the previous version of a thing.

Actually, what I really hate most is not the issues I've had, new systems often have warts and we should encourage discussion to get them fixed.. not shut them down when problems are shown because there _are_ problems.. my issue is how under-represented other init systems are, I didn't like systemd and was basically told (by developers, mostly) to "suck it up" and to stop "getting in the way of progress", and while I've never tried to defend sysVinit, I was always keen to have a discussion about a _well engineered_ solution to this would be.. somehow SystemD has taken over and it's more windowsy than we imagined and growing daily.. it even has a bootloader now.

Nosh is a cleaner implemented init system and so is SMF, they fix a problem and do so well..

systemd works great on my laptop though! (arch linux)



So, this isn't exactly a tech support forum, but...

Does your Arch Linux system consider nr_inodes=0 to be a valid mount parameter for tmpfs? If it does, does it use systemd 225?

I upgraded to Kubuntu 15.10. On first reboot, I found that my boot failed because the system claims that tmpfs does not accept a value of 0 for the nr_inodes parameter.

It has been documented for a very long time that "0" for nr_inodes, nr_blocks, or size means "unlimited". My Gentoo Linux systems running kernels from 3.x through 4.2.x have always happily accepted this value, so I know this isn't a mainline kernel change. Kubuntu 15.04 also accepted this value.


Got some links to the 802.3a/d bonding issues?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: