I think you keep missing my point. This isn’t about a “usual web form”. You aren’t entering your address or something. You’re configuring a service or server. Those are very different worlds. I understand that those kinds of forms where you enter your address (or whatever) wouldn’t ever have a default in there. In that context a default doesn’t make any sense (default name, default street, default city?). And even in the cases where it might, it would be - as you pointed out - unexpected for the kinds of users that usually fill out “web forms”.

When you’re configuring a server/service, that’s a very different world. Many fields could have defaults, and you wouldn’t want to hard-code those into your config. That is what this is. It’s essentially a web interface for a config file, which often has default values for any field you don’t specify for a variety of reasons. Defaults DO have special meaning here. That’s the whole point I’m trying to make! In that world it very much makes sense. The best way to show it is obviously a matter of personal taste, I actually like (and prefer) the greyed out way for reason I mentioned above.

Being shown what’s the default isn’t the same as having it actually in the field. For example the default might change, then these values would change with the default. There are also cases where they are inherited or something similar, where the upstream value isn’t as fixed as defaults normally are. So there is a functional difference to showing you a greyed out default and actually having that default be in the field.

Especially for things that essentially are a web interface for a config file where the config file gets larger with values that aren’t needed (this includes both NPM and Proxmox, as examples). Instead of like 3-4 lines it could now be like 20. It also becomes unclear when looking at the values later if they were actually set to that value intentionally or if it just happens to be the default that got filled in because some UI was used that filled all fields with their default values.

Showing the default outside in a label or as a tooltip-hover is an option, but has implications for the space needed and readability. And this way is actually much clearer if you want to look over a config and you need for example the default port or something, it’s in the exact place you expect it, shown in grey to make it clear that it wasn’t set intentionally but that it’s just the default. In some UIs there’s room for defaults, in some not. I personally vastly prefer them to be shown like this, as you might have guessed already.

Yea I realized that only after. I agree it’s slightly different from the grey text in text fields, but it still illustrates the point because it’s also an implicit default value (that happens to be unchangable in this context). So it kinda applies, but yea not quite the same.

I’m coming from the perspective of administrative interfaces, not generic forms. See my other reply for the examples that I use daily that made me have a different “intuition” here. Edit: But the fact that I got three replies in like a few minutes also shows that my perspective might not be the universal one. Still, I think it does hold up in the context of administrative interfaces (which is what NPM is).

always […] why would it be an implicit default?

Cause that’s what I intuitively expected, because in the tools that I use daily, that how it is there. Here are some examples of other administrative web interfaces that use grey to show you the implicit default that I happen to have running and could find in like 3 minutes. So much for your overconfident “always”:

• Proxmox PVE or PBS. Basically every dialog. Example network interface configuration:
• TrueNAS, example “Add Dataset”
• OPNsense, example “Firewall Rule”, the destination port range has an implicit default and is grey:

Note: I’m not talking about a form to fill in your name with “john doe” or whatever, and even that I can’t even remember seeing either. Cause it just says “Name:” and nobody needs an example.

80 being grey suggests it’s the implicit default, not an example. Like in any other input mask like this. That is a very reasonable company and not intuitive at all.

If I remember right, problems of that type are either NP-Complete or even NP-Hard, meaning they are incredibly hard to compute and/or don’t have a known solution. They have been studied for centuries, so there should be ample scientific research (see the links the other commenters posted already), but my point is a “perfect solution” probably isn’t a realistic goal. I would aim for an approximation that’s “good enough” for your use case.

I’m actually almost never using it locally, but find it very useful in remote ssh sessions. There I often don’t want to lose whatever task just cause I disconnect.

Tried zellij yet? The first one I stuck with and didn’t stop using again after a few days cause I can’t just remember key binds.

In Germany also the employer. If you are self employed, my understanding is that you don’t have a salary as such, so it doesn’t apply. But if you own your own company, where you work (as the CEO or whatever) and have a salary, that company pays you, even if you own it.

Another important point that these overviews don’t convey: if you are on vacation (be it abroad or at home) and you get sick, you get your paid leave time back and you can take it another time. There’s some asterisks attached to this, but generally that’s how it works. There’s a big emphasis on the text that your vacation days are yours. To regenerate, just relax or whatever you wanna do. So being sick “doesn’t count”, basically.

I have a love-hate relationship with it. Due to work reasons I’m more familiar than I want to be with tortoiseSVN, and the git version is similar enough to feel at home. But that’s also it’s biggest downfall: it does a lot of things the “SVN way” despite being a git client. The workflow can be kinda made to work, but it always feels like it’s not a native git tool, because it isn’t. I would go so far as to say that it encouragedrl bad habits on git, especially for those used to tortoiseSVN.

I kinda get it for immutable distros, where you can’t just install dependencies. But other than that the appeal is also very lost on me.

They probably have good reasons to that are less obvious. If they didn’t have an order already, I think it’ll take 10-15 years for anything they order to be delivered by Airbus (assuming no delays, too). So maybe they just can’t wait and others stop buying Boeing (also for good reasons, obviously), so there are spots open or something?

Braun is US owned these days. From trying to find out, it got confusing rather quickly as it isn’t a company anymore, but just a brand name. It seems to have been split depending on product type (electric razors, electric toothbrushes, coffee makers, …). I have to be honest I kinda gave up trying to find out specifics at that point and just avoid them now instead.

I’m aware of that, and didn’t say otherwise?

My comment wasn’t even ipv6 specific, quite the opposite. The comment I was replying to also wasn’t, and the implication that things would be better if everyone had a fixed IP(v4) was actually the specific privacy nightmare scenario I wanted to emphasize. That is the literal worst case of all.

Things can be mitigated somewhat with IPv6, but also only to a degree. Here you’d (usually) have a static prefix and not IP. You then need to use the randomized suffix generation (on a host level, or in DHCPv6 if you’re using that), and not all OS so this by default, but I think Windows does these days. Advertising data collectors, which means basically every web site, could just assume that your prefix is stable and the information they gain if they happen to be correct it’s… uncomfortable.

You can run a basic server with an old laptop, desktop, mini-pc, anything. Everyone starts somewhere. If you eventually need ‘more’ or ‘better’, you can figure things out then. Getting started with a used office PC for 40$ off eBay (or anything old you already have) is fine. Just get started.

Everyone having a static IP is a privacy nightmare.

There’s a reason the recommendation in the standard for ipv6 had to be amended (it whatever the mechanic was) so that generated local suffixes aren’t static. Before that, we were essentially globally identifiable because just the second half of your v6 address was static.

The 2nd and even 3rd point is not automatically true for every phone and setting. I have a combined fingerprint reader and power button on my Fairphone 5, and the 2nd thing has always worked just fine.

It also has the option to only enable the fingerprint reader if the display is on, which addresses your 3rd point completely. It means you can pick the phone up, including having a finger in the reader, and it won’t turn on or unlock. You need to press down in the button to trigger the screen, then it can be unlocked. That also means that when locking it and turning off the screen actively by pressing the power button with the phone on, it never re-unlocks. To be honest this part wasn’t a problem before the setting became available, as the locking would disable the fingerprint reader anyway, but letting your grip go slightly could trigger re-unlock.

Keepass just uses a (local) file, but it expects and can handle if the file is modified externally. That’s important because it means you can store it on a network share, or in some sort of synchronized storage, self hosted or not (next cloud, sync thing, Google drive, whatever). It’s just up to you. If you have it open on your PC and you add an entry on your phone, your PC won’t “overwrite” it, but integrates any changes you’re making there at the same time.

For example the android client has direct support for a long list on storage services for this exact reason.

So you’re basically saying “I don’t have any proof of any of this, but I’m scared so I’m scaring others as well”.

Your first point makes zero sense: it can’t be both “for profit” and have “no means of generating income”.

Their way of generating income is the reason they created the distro/OS in the first place: selling hardware. To my knowledge, they wanted to ship their mini servers (ZimaBoard) and later NAS-like devices (ZimaCube I think?) with an easy to use OS that can do all basic home server tasks. That didn’t exist, so they made one. They didn’t need to make money from the OS, it’s a catalyst to bring able to sell (more) hardware. I personally think that is a great way to use Linux as a company and contribute to the wider ecosystem, why does it scare you so much? They could’ve closed this of much more, but made it for available to everyone, on any hardware.

From what I heard, they did achieve their design goals. It’s a bit simplistic for me personally, but probably great for a beginner.

I get that enshittyfication is everywhere these days, but maybe don’t try to stop people from using things that haven’t actually seen ANY yet, just because they might? With no indication that they will, either.

4&5 might be fair points though, I for know enough about the details.