Hacker Newsnew | past | comments | ask | show | jobs | submit | grantla's commentslogin

> also proxmox is German.

Austrian, please.


ah, Wien, my bad :)


> as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again

Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.


Yeah, I know, I spent more than a week into looking for options to reduce impact for all of our users.

And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, maintaining triple digits of them sure has its cost too.

And don't understand me wrong, sunsetting cgroupv1 was reasonable, but it was a lot of churn, it at least was a one time thing. The network interface naming situation is periodic churn, guaranteed to bite you every now and then just by using the defaults.


Can you tell me why NamePolicy=keep doesn't do the trick?

Looking myself for options to keep a Debian bare metal server I admin from going deaf and mute the next time I upgrade it... It still uses an /etc/network/interfaces file that configures a bridge for VMs to use, and the bridge_ports parameter requires an interface name which, when I upgraded to Bookworm, changed.

At this rate maybe I'll write a script that runs on boot and fixes up that file with whatever interface it finds, then restarts the network.


> A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as Gentoo don’t have it that easy.

For Debian it was extremely painful. A few people probably burned out. Lots of people pointed to source-based distributions and said "they will have it very easy".


> For Debian it was extremely painful.

Do you have any references that elaborate on that? From an outsider perspective, the time64 transition in Debian seemed to have been relatively uncontroversial and smooth. Way better than e.g. the /usr-merge.


https://lwn.net/Articles/812767/

https://wiki.debian.org/ReleaseGoals/64bit-time

I'm continually impressed by Debian. My Debian systems are pretty boring, so maybe it's to be expected, but as an end-user neither the /usr merge or time64 transition broke anything for me, and I'm using Testing.


> For Debian it was extremely painful.

I did the transition for m68k, powerpc and sh4 and partially for hppa with the help of some other Debian Developers here and there and I'm still alive ;-).


> For Debian it was extremely painful. A few people probably burned out. Lots of people pointed to source-based distributions and said "they will have it very easy".

'easy' in a way "just tell the user to rebuild everything in one go"? :)


Care to expand on the "non-existent server" part? This is probably an oversight (missing tests) in the API impl.


Wish them good luck. They will find out how incompetent Nokia became.


From experience in other EU countries, registering SIM-card registration helps exactly nothing. The biometrics also won't help.


Of course it doesn't. Especially with the low roaming costs inside Europe. Just grab one in another country and use that. It's purely theater. This is why it's so annoying.

My current provider Orange even requires me to re-ID at their shop periodically now :(


SMS really just needs to die, and we'll all be better off.


If we are talking about phone numbers for humans - maybe true. Phone network routing numbers can and do contain A-E.


I mean, for the purposes of `libphonenumber`, PrioA-D is not used.

Also, as far as I know most things are sent out-of-band anyways, but I wouldn't be surprised if there's some legacy system out there which work only on DTMF.


PCLATH is not actually the program counter; the real PC is only updated at GOTO/CALL time, and then PCLATH will be copied over.


Counterpoint: the moment you do receive spam calls in Austria, our regulatory office is so incompetent, they'll not do anything about it. Last time their reply was "this is a VOIP number and it's already disconnected, so we cannot figure out who the caller was" ... after waiting a month before contacting the involved carriers.


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

Search: