Not anymore because all the reason I mentioned. Has the experience change in recent years? Not likely. It is the same software as in other distros - just years out of date. That has not changed as the goals of these projects have not changed. They might be on newer versions then 10 years ago but they are still way behind more frequently updated distros - or at least will be very shortly. That is fundamentally how these enterprise distros work. Their target audience is businesses needing support, not lots of end users.

The big attraction towards these distros are the support that enterprise people will pay for - which you do not get with the free version. If you don’t mind older versions of things then it might be nice for you. If not then I would stay clear of them.

Older software is the most noticeable thing. Enterprise does not mean it is better - just that it is supported for a long time and they do that by not changing much on them. They are more designed for servers rather than workstations and generally not a great experiences unless you are running hundreds or thousands of them in an enterprise situation.

Professional just means payed for. What you are paying for is support in managing the systems, not a great user experience.

For home desktops it is far nicer to be on newer software rather than things that came out 5 to 10 years ago.

If that were the main goal why not just ban them from the extension store? Or why allow manifest v3 extensions to block requests at all? Ad blockers still work and this did not kill off any of them. Just forced them to change some of their functions. I don’t doubt the executive overlords are happy about the turmoil that this has done to ad blockers but they would be pissed if that was the only or main goal of this as there are still loads of effective adblockers about.

That is a more complex story then that. The manifest v3 changes primary give a lot of security and privacy changes that stop extensions from doing a lot of questionable things in the background on all your page you visit. But that does stop ad blockers from doing a lot of what they currently do - blocking in page elements and modifying the pages you visit. But it does not block them from blocking page requests so ad blockers like ublockorigin lite can still function in a more limited capacity to block ads.

I do think the teams outside of the chrome team are happy for this change - but I don’t think the chrome team set out to do this purely or even mainly to block ads.

Besides even if they did it does not change my argument - whom ever buys chrome will likely want to squeeze it for more money then google currently are doing and will likely do far worst things like including ads directly in the browser. Or trying to monetize it in some other way.

I would love it if chrome where maintained by some non-profit foundation. But how likely is that going to be from a court order sell off?

I would rather they split up google in other ways first.

TBH I am not sure this will end well at all. Google needs to e broken up but splitting off chrome? What will that achieve? Chrome does not directly make any money for Google really, they don’t sell it, they don’t sell ads in it, they don’t even collect much personal data though it. No where near as much as they really could if they really wanted to. Google have not been terrible at managing chrome or pushing as much profit out of it as they could.

Instead they are using it to create a good platform for all the rest of their services where they actually make money. So what will selling off this loss leader do for chrome? Most likely it will get bought up by someone else that will want to see a return on investment that wont be using it as a loss leader. Which I can very well see it getting en-shitified like everything else that is purely driven by profit.

Best case it is gets bought by a non profit foundation that can develop and take care of it - but lets be real, they wont have the money to out compete anyone wanting to buy it to make more money.

I personally don’t really trust google with my browser either - hence why I avoid chrome. But I would trust anyone seeking to buy it for profit far less and can very well see this as a overall negative if the wrong people buy it (which I see as more likely).

That being said, I don’t keep one in my car.

Now is the time to change that.

Um no. Containers are not just chroot. Chroot is a way to isolate or namespace the filesystem giving the process run inside access only to those files. Containers do this. But they also isolate the process id, network, and various other system resources.

Additionally with runtimes like docker they bring in vastly better tooling around this. Making them much easier to work with. They are like chroot on steroids, not simply marketing fluff.

I disagree. What is wrong with a fully featured batteries included desktop environment that has proper tiling support (not just partital drag the window to the edge of the screen support). Lower the barrior to entry so that more people can make use of this powerful way of working. The main reason that tiling is considered hardcore is becuase it has mostly only been available on minimal configure them yourself window managers. But tiling does not have to be for the fully DIY only crowed.

IMO the basic tiling support on gnome or KDE are not good enough. So I am forced to use something minimal but TBH I am sick of needing 100s of lines of config to get a basic environment setup. Cosmic seems like it will be a good answer to this post as its tiling support looks far more fully baked than other full desktop environments and hopefully we will see more people wanting to try out tiling once it reaches a more stable point.

We spent much of the year fighting these dangerous “child safety” bills, while also pointing out to legislators that comprehensive data privacy legislation would be more likely to pass constitutional muster and address many of the issues that these child safety bills focus on.

Because they don’t actually care about child safety. massive online censorship and surveillance is the goal here - kids are the excuse they are using to try and get it to pass as it has no hope in hell without some sort of mask on it. The only things they ever do for children is banning abortions and erode privacy. Never anything that would actually help, like feeding them in school, or better prenatal support and leave at work, or medical insurance for everyone. Instead they fight against these measures and for things that won’t help children in the slightest.

Anything is possible with sockets… and that is a meaningless statement. It is like saying you can build anything with bricks. Technically true, but missing all the important details of how.

In an alternative universe we could have done so many things differently to solve the same problems. But we don’t live there and in our universe dbus was the attempt to solve that problem among others. And yes you can create a standardization for music players easily enough - but what about notifications, and everything else? DBus tries to be a generic interface anything can talk over at a logical level - rather that just being the basic way two process can physically send bytes between each other.

Sockets are just streams of bytes - no defined structure to them at all. Dbus is about defining a common interface that everything can talk. That means when writing a program you don’t need to learn how every program you want to talk to talks over its own socket - just can just use a dbus library and query what is available on the system.

At least that is the idea - IMO its implementation has a lot to be desired but a central event bus IMO is a good idea. Just needs to be easy to integrate with which I think is what dbus fails at.

A great example is music player software - rather than every music player software creating its own socket and each having its own API to basically all do the same operations. So anything that want to just play/pause some music would need to understand all the differences between all the various different music applications. Instead with a central event bus system each music app could integrate with that and each application that wants to talk to a music app would just need to talk to the event bus and not need to understand every single music app out there.

Don’t forget about the blue passports!

I think it is for travel and hospitality places. Not something you would typically buy in a shop or liquor store but more a hotel or at an airport or similar.

(for example) a 250GB drive that does not use the full address space available

Current drives do not have different sized addressable spaces and a 256GiB drive does not use the full address space available. If it did then that would be the maximum size a drive could be. Yet we have 20TB+ drives and even those are no where near the address size limit of storage media.

then I suspect the average drive would have just a bit more usable space available by default.

The platter size might differ to get the same density and the costs would also likely be different. Likely resulting in a similar cost per GB, which is the number that generally matters more.

My comment re wear-levelling was more to suggest that I didn’t think the unused address space (in my example of 250GB vs 256GiB) could be excused by saying it was taken up by spare sectors.

There is a lot of unused address space - there is no need to come up with an excuse for it. It does not matter what size the drive is they all use the same number of bits for addressing the data.

Address space is basically free, so not using it all does not matter. Putting in extra storage that can use the space does cost however. So there is no real relation between the address spaces and what space is on a drive and what space is accessible to the end user. So it makes no difference in what units you use to market the drives on.

Instead the marketing has been incredibly consistent - way back to the early days. Physical storage has essentially always been labeled in SI units. There really is no marketing conspiracy here. It just that is they way it was always done. And why it was picked that way to begin with? Well, that was back in the day when binary units where not as common and physical storage never really fit the doubling pattern like other components like ram. You see all sorts of random sizes in early storage media so SI units I guess did not feel out of place.

Huh? What does how a drive size is measured affect the available address space used at all? Drives are broken up into blocks, and each block is addressable. This is irrelevant of if you measure it in GB or GiB and does not change the address or block size. Hell, you have have a block size in binary units and the overall capacity in SI units and it does not matter - that is how it is typically done with typical block sizes being 512 bytes, or 4096 (4KiB).

Or have anything to do with ware leveling at all? If you buy a 250GB SSD then you will be able to write 250GB to it - it will have some hidden capacity for ware-leveling, but that could be 10GB, 20GB, 50GB or any number they want. No relation to unit conversions at all.

I shouldn’t expect remote accessing some random server will allow me to use Helix, right? Is there any other way to make this work? Or…, should I just learn both Vim and Helix’ Vim + Kakoune amalgamation?

That all depends on the server in question and if you can install things onto it or not. Some points to consider though:

• If the server is restrictive on what you can install then you likely are stuck with basic vim or worst only vi - and without all your configs it is a very different beast of an editor anyway and something you will need to get used to everytime you jump on the server.
• If you can install stuff to your home drive then it is quite easy to get helix running - it is a single binary with some language assets (requires one env var to point to them). So is trivial to get working from your home dir without a package manager.
• IMO you should not be editing things on a server often enough to worry too much about what editors it has on it. Ideally with things like ansible you should not need an editor on it at all.

Vim is literally ubiquitous and plugins that enable its features can be found on almost any ‘platform’. It’s unrealistic to expect Helix’ adoption to be at that rate (yet). However, would you happen to know if at least the likes of VS Code and/or Jetbrains’ IDEs support it? And if so, how good their support/implementation is?

Do you mean vi input mode in other editors? That is one downside - you wont find it anywhere yet. Though since learning it I have not needed to go back to other IDEs like VS Code or Jetbrains, WIth inbuilt LSP support its language integration is just as good as VS Codes as it is working off the same essential language servers. Though it does seem that at least vscode has a plugin for kakoune keybindings which are more similar to helixs.

Though what you will find is a lot of the keys are very similar between vi and helix, so apart from the big action > movement vs selection > action and a few other things they dont feel too dissimilar from each other (things like basic movement, ie w for word, e for end of word, or text objects are essentially the same).

deleted by creator

Interesting. Though I can definitely see where you’re coming from. Uhmm…, have you used any of the Neovim distributions to make maintenance easier?

I have, but dont like them. They all have weird install processes and need to manage their own set of configs on top of vim in your home dir. This makes them very hard to properly package or integrate with config management tools and require a different flow to keep them up to date from the rest of your system. They combine sometimes hundreds of plugins, of which only a few are designed to work together and while a lot don’t try to step on each others toes that many I often find issues in niche use cases. And when you do find an issue, or something you want to tweak you have 100s of plugin configurations that you need to learn about to figure out just what is doing what and which options you need to tweak.

It is all just far more hassle then I want out of my editor these days. Helix just works out the box and has basically everything I want from a editor nicely integrated into it.

As you’ve touched upon it; Helix’ keybindings and ‘sentence-structures’ are different to those found on Vi(m).

They are a little different and take a bit to get used to. But IMO I find them far nicer way to work. It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys. And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often. It is not trying to be a 100% vim compatible layer, it is trying to give you the best experience it can out the box. And I think it does that quite well (at least once you get used to the new way of working - which does not take that long).

Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there’s no guarantee that I can keep using either of the two 20 years into the future.

20 years is a long time. I can see it existing for the next 5 years at least, and looks to be on the trajectory to be a long lasting product. Though no one can say for sure. But, the more people using it the more likely it is to stick around for the long term. Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).

And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.

I appreciate the input, but I simply don’t want to invest in a program whose future is very unclear to me at this point in time.

The investment in helix is far less then that you need to put into vim/neovim due to all the configuration you need for them. Well worth it for how active it currently is and how many people are putting effort into it.

I have used vim/neovim for years and cannot go back to a non-modal editor. But TBH I got sick of its configuration. You need far too many plugins and config to get things into a sane working order to be usable on a day to day bases for any type of development. It takes ages to learn and become as productive as you were before and a lifetime to refine.

For the past year or so I have switched to helix and don’t plan on going back to vim/neovim as my main editor ever again. It is a modal editor that is a mix between Neovim and Kakoune editors. It comes with batteries included, and supports an IDE like experience out the box with treesitter syntax highlighting and LSP language integrations out the box. My whole config is like 6 lines long yet it works far better then my old neovim setup with a multitude of plugins and hundreds of lines of config. It is like what AstroNvim, LazyVim, LunarVim and NvChad etc are trying to do to vim/neovim but instead has built in support for all the things they rely on plugins for. Which means there is no need to constantly keep them up to date nor weird edge cases where one plugin does quite integrate with another smoothly. It is all built in so things are designed to work well together.

But it currently does lack any plugin support. So if something is not built in that you want you have to make due without it (well, except language support, adding new LSPs is not too hard). And plugin support is being worked on so even this will be a non-issue hopefully in a year or two.

I am not sure that is quite right. I dont think rust support just enabling dynamic linking of its dependencies. It can talk to dynamically linked libraries - which is how FFI works. And you can compile rust crates to be dynamically linked. But when you are going down this route you are talking over the C ABI. This requires some effort on the code author to make their APIs exportable to C types and means you lose all safety when talking over the C ABI.

I also dont think that rust inlines across a crate boundary unless the function is marked as inline or LTO is enabled - inlining across crate boundaries is expensive and so only done when explicitly needed or asked for it. It is more that you lose features like generics and traits and other things that are not supported over the C API.