People said the same thing about tweet when twitter first came out.

Secureboot is meant to help protect you against the evil maid attack. IE someone with physical access to your computer can compromise your boot loader with a keylogger that can capture your encryption password so that when they return they can gain access to your computer as they now know your password. Though the vast majority of people just don’t need to worry about that level of attack so I have never really bothered with secureboot.

I would say it is more so they can advertise a lower price. But then expect you to get the more expensive ones as the bare minimum is just not enough.

Use whatever that distro recommends then - which as far as I can tell seems to be svlogd for runit based systems. Though you should consult their documentation and make your own decision on which logger to use.

There is also the BREACH which targets gzip/deflate compression on http as well. But also, don’t see how that affects disk encryption.

Looks to be an exploit only possible because compression changes the length of the response and the data can be injected into the request and is reflected in the response. So an attacker can guess the secret byte by byte by observing a shorter response form the server.

That seems like something not feasible to do to a storage device or anything that is encrypted at rest as it requires a server actively encrypting data the attacker has given it.

We should be careful of seeing a problem in one very specific place and then trying to apply the same logic to everything broadly.

How does that work? Encryption should not care at all about the data that is being encrypted. It is all just bytes at the end of the day, should not matter if they are compressed or not.

You dont need syslog. Journald is good enough for most systems.

It also does not support unix file permissions - so for most installs it does indeed not work.

Ext4 codebase is known to be very complex and some people say even scary. It just works because everybody’s using it and bugs have been fixed years ago.

I heard that ext4s best feature was its fsck utils being extremely robust and able to recover from a lot of problems. Which does not shine a great light on the filesystem itself :/ and probably a result of the complex codebase.

bcachefs is meant to be more reliable than btrfs - which has had issues with since it was released (especially in the early days). Though bcachefs has yet to be proven at scale that it can beat btrfs at that.

Bcachefs also supports more features I believe - like encryption. No need for an extra layer below the filesystem to get the benefits of encryption. Much like compression that also happens on both btrfs and bcachefs.

Btrfs also has issues with certain raid configurations, I don’t think it yet has support for raid 5/6 like setup and it has promised that for - um, well maybe a decade already? and I still have not heard any signs of it making any progress on that front. Though bcachefs also still has this on their wishlist - but I see more hope for them getting it before btrfs which seems to have given up on that feature.

Bcachefs also claims to have a cleaner codebase than btrfs.

Though bcachefs is still very new so we will see how true some of its claims will end up being. But if true it does seem like the more interesting filesystem overall.

Sure, my bad. But it does not change my point. They have released stuff as opensource even if not all of it. Which means they can if they want to.

The wrote and released VS Code - a completely opensource development environment. If they wanted to patch Grub I bet they could have found the permissions internally to do that. Microsoft is a lot more open to OSS contributions then they were in the past.

For me, I like the idea of a tiling window manager with batteries included. Been using tiling window mangers for ages now and cannot go back to floating window management. But all the tiling window managers are bare bones and configure everything you want from the ground up. Which I am not a huge fan of these days. I want something to work out the box with first party full tiling support (not just dragging windows to the side) but without needing 100s of lines of config to get a half decent setup.

There are basically two different versions of Cosmic. The current one which is basically just an extension for Gnome. This is what has shipped with PopOS and currently still done.

But system76 had a vision for what they wanted and they did not feel building that as an extension was sustainable long term. They had a bunch of stability issues (ie gnome breaking things in newer versions they were using). So they decided to write a new desktop environment from scratch in rust that they had full control over.

I believe that the new Cosmic sits somewhere in between KDE and Gnome in terms of customization - or at least what they are aiming for. No where near the level of settings as KDE but not trying to remove every option like Gnome.

And being a new project written from scratch it is forward focused - and only support wayland.

You can read more about their decisions in a recent blog post: https://blog.system76.com/post/cosmic-team-interview-byoux

What? Microsoft have written and released and contributed to many open source projects - they created vscode for one. They are even one of the top contributors to the Linux kernel.

uptime of 840 days

This always makes me wince. I don’t think high uptimes should be celebrated. Has your kernel ever been patched or the services running restarted? Just installing the updates is not enough to secure your system you need to be running that new code as well.

Also, I get very nervous about touching those systems. You have no clue what state it is in. I have seen far too many large uptime server have their power go some day and are never able to boot again or don’t boot all the services back up as someone forgot to enable the service.

Nop, rather see them rebooted regularly at a non critical time so we know they will come back up. Or even better have a HA setup.

This does not work for everyone. A lot of people will try to switch, but find one tool they are used to they cannot now use and are not used to the alternatives so feel frustrated when trying to use them for real work. Then get pissed off at Linux and switch back to windows.

This advice is more for people that are thinking about Linux but have some professional or semi professional or hobby workflow on their computers that they need to be productive in. It can be very hard for them to switch os and tooling they are used to with no way to fall back to what they know when they need to.

You will find most people don’t rely on these tools and they can doba quick check and decide to switch straight away. But ignoring this advice for the rest can make transitioning to Linux easier.

We need to stop pretending that switching tools that you rely on and have spent decades learning to be proficient in is a trivial task for everyone.

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…

It makes no sense.

But no one actually pulls that rule through, do they?

They do though. Loads of new people to programming read that book and create unreadable messes of a code base that follow all of his advice. I have lost count of the number of times I have inlined functions, removed layers of abstraction and generally duplicated code to get a actual understanding of what is going on only to realize there is a vastly simpler way to structure the code that I could not see until all the layers and indirection are removed. Then to refactor again to remove redundant code and apply more useful layers again that actually made sense.

And that is the problem we have with his book. People that need it take up as many bad habits as they do good ones leading to an overall decline in their code quality. It is not until years of experience that you can understand the bad bits and ignore them. So overall his book is a net negative on the programming world. Not all his advice is bad, but if you can tell that then you likely don’t need his advice.

But on the layers of abstractions specifically, he takes this too far. Largely because of the 4 line limit he has. There is a good level of abstraction and I generally find more than 2 or 3 levels of abstraction is where I start to loose any sense of what is going on. He always seems to jump on abstraction as soon as he can, but I find waiting a while and abstraction when you need to to lead to fewer and vastly better layers of abstraction overall.

And adding more abstraction does not help the people of people doing too many things inside a function - they just move it to sub functions rather than extracting the behavior for the caller to deal with. I have never seen him give advice on what that is appropriate, only keeps the functionality of the original function the same and move the logic into a nested function instead and that only covers up the issue of the function doing too much.