There must have been so many "unforeseen" blockers from the basic design idea up to this 1.0 release. And indeed, it appears that the sway developers have walked the walk.
Pareto's Principle at it's best.
Anyhow.. Congratulations to this truly impressive achievement.
Yeah, software takes more ram, so when your ram is full your computer is slowed (because it probably doesn't need only 100% if your ram), therefore you buy more ram. Now guess what? your ram is not at 100% anymore, your unused memory is wasted anyway, so why not use it?
Not exactly -- more like no matter how much RAM you have, it makes sense for your software to use it all rather than disk.
It means that however much you have, your system should use as much of it as possible. Otherwise it's just sitting there doing nothing. Contrary to popular belief, the more RAM you're using, the faster your system will be (assuming it's using the RAM efficiently)
It should gradually trend towards using the vast majority of the free space. The disk cache won't consume memory unless you're reading new, not-already-cached pages from disk; so if you're not reading enough data from disk, then it might not consume everything. (E.g., if you've rebooted recently, and just haven't read enough from disk to consume everything.)
If you work w/ removable media, IME the cache will free the pages associated w/ that media when it's removed (as the cache must be assumed invalid when/if the media is plugged back in). Playing a DVD, and then ejecting it, would often result in a large drop in disk cache. (Back before Netflix…)
While valid and interesting (good to know, and to share) for most people GNUPG-signed+encrypted emails are nice as a privacy protection tools against mass data mining. Even in today's society I't a bit hard to imaging Alphabet, Yandex, Microsoft etc do such kind of attacks...
Yes, but i believe tools/features like these advertise a sense of a level of security to the user which is, evidently and also to the protocols involved inherently, not what they might be led to believe. Given it's usually sensitive context, this can be quite dangerous.
That's really too bad -- are there no other FBSD alternatives that are maintained?
Also -- I am going to get flamed for this -- but a GPL license would have forced Google to upstream their Capsicum changes wouldn't it -- whereas the BSD license doesn't have such a mandate.
The GPL doesn't force people to upstream their changes, although it often has that affect. The GPL only forces you to give source downstream. If your customers never share the source with anyone else (and your upstream is not one of your customers) then your upstream will never get the changes. A good example of this is the game TOME. It has downloadable content that is licensed under the GPL. You get the source code when you buy the DLC. I've never seen anyone distribute it, though (and it's highly frowned upon in the community). The author has a weird idea of the GPL, though, so I don't think he really understands that anyone is allowed to distribute that code.
But in practice people usually freely distribute GPL code, so it's impossible to stop your upstream from eventually getting it.
it would be somewhat counterproductive to introduce yet another sandboxing mechanism, just to work around a problem created by upstream - especially in case of mechanism as awesome as Capsicum :-)
Yes, the GPL license would force them to share their changes. Thing is, they wanted to upstream them anyway - AFAIK the problem is on the other (accepting) side.
Yes, i guess there is little doubt that capsicum is the superior (compared to seccomp) capabilities framework, but if it's not used outside of FreeBSD's base, (e.g. ssh, bhyve, etc.) then it is indeed a shame.
I think if something like XFCE were to implement xmonad / dwm style tiling, that would be about perfect. I like some of the creature comforts of a desktop environment, but I prefer them to heavy on supporting features, and light on in-your-face features.
Also, I cannot stand the ubiquitous hamburger menus of Gnome. I really wish we could all go back to humane menus.
I completely agree. I used to be a heavy xmonad user, but I've had to be on macOS for work the past few years. I've found emacs to be a suitable substitute for a tiling window manager for the majority of my use cases and then have macOS for the creature comforts part. I've been test driving KDE Plasma recently at home, and it's quite nice these days. I wouldn't call it fast compared to other linux desktop environments, but it's pretty snappy compared to the KDE I tried five years ago. It was pretty simple to get it looking and feeling similar to my mac environment, and then emacs is always emacs. I do wish there was a more modern feeling TWM, but for now I like having something family/friends/coworkers can comfortably navigate when the need arises.
Honestly this not that odd. If you have local users with no password (not normal), and ssh exposed, you prob have bigger issues. Do agree tho, this is a stupid default and surprising it got past any sort of system hardening checklist.
iirc, OpenWRT also uses password-less root access via ssh by default and indeed, one might find these kind of configs in provisioning setups quite often. What are the options these days besides default user/pw? The (Plastic)Router from my ISP has this sticker on the back with a custom default pw for user access. Always wondered how this works.. probably somehow derived from MAC addresses and/or other factors.
Anyhow.. Congratulations to this truly impressive achievement.