Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal.
Many users have a poor understanding of what Flakes _actually_ are: They are a bit of UX glue on top of existing Nix features:
- Input/output schemas for `flake.nix`
- A lock file format
- CLI features to work with the two above
It's entirely feasible to build out a Flake user interface & evaluation support on top of Tvix without making it a first-class evaluator feature.
See https://github.com/edolstra/flake-compat for prior art.
The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
> Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal.
Except that it rolls its own CA store[1], which is also not a stable Nix feature. One could argue that it has to roll its own store because Nix wants to own the store, but implementing a shadow version of an experimental feature makes the "they're just targeting stable features" part ring rather hollow.
> The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
That's not really how I read the authors' defense of this choice. It seems like they made it because they disagree with the design decision, and I consider that more defensible than the position you offer. I just wish they would make this information more central, and I will keep posting it in news items about Tvix because no one else is going to. There is no indication that the "Nix" they implement is many years old now, and when they do[2] indicate it, they are vague about why.
Flakes are a misfeature that adds a complicated layer of abstraction over an already not very simple system.
I follow some chats with lots of Nix beginners, and the amount of people that are now stuck in a flakes tarpit and have no understanding of the fundamentals of Nix (and no path to get there, really, in the course of normal usage) is depressing. Just the other day I saw someone post a 40 line Nix code snippet using flakes, pulling in 2 git repos apart from nixpkgs (because the barebones flakes are barely even usable without support libraries), all to make a simple nix-shell with a single package in there - and it didn't even work and they were unsure how to proceed with debugging.
In almost all chats with flakes proponents it also eventually turned out that what they want is something like niv, but integrated into the Nix binary, not all of the additional stuff that is attached to flakes.
Anyways, adisbladis' point is that Tvix does not need to support flakes in any way. If you really want to add these complications to your Nix code, you can implement everything flakes do in pure Nix (using e.g. the flakes-compat thing linked above).
Sure, and this is all fine, but it feels like this information gets buried or smoothed-over, and I think you strengthen your position by leading with it as a differentiator. Nobody new to Nix knows what targeting 2.3 means, but they likely know what flakes are, and you aren't doing a lot to make it clear why they should prefer a fast language evaluator to something that can handle flakes.
This is only true if use a Docker based workflow using `FROM nixos/nix`.
This image exists mainly as a way for people to try out Nix with, not to build production images on top of.
We ship many things which bloat the image size but makes it nicer for interactive usage.
Using dockerTools from nixpkgs is much better and gives you much smaller images closer to Alpine size.
I might have confused download volume with image size but the tar.gz for dockerTools.buildLayeredImage with just node and mariadb in the contents is still 220MB (just checked)
Edit: with nothing in the contents it's 144M, which is getting reasonable but still nearly 30x alpine base
Lenovo's paid warranty has been fantastic for me in the multiple countries where I've used it (Sweden, Hong Kong and Mexico).
In all three they sent out a local service technician that fixed the problem on-site.
Once it was a a worn out SSD that was replaced with one twice as big as that was the only thing they had in stock (Sweden), another time it was a broken connector on the motherboard (Hong Kong) and the third time it was a broken display (Mexico, Cozumel).
I was most impressed by the service in Mexico as it's pretty far from any major cities and the technician came out after only a day.
If good warranty service is important to you I cannot recommend enough to get a Lenovo (T, P or X series) laptop and shell out for the extra warranty.
Not OP, but when I tried Wayland way back when, I discovered that libinput didn't let you remap tap buttons, something Xorg does support. That feature is incredibly useful for me, since my touchpad has no physical buttons but does have a dedicated right-click zone, so it's useful to remap two-finger tap to middle-click, since I use that all the time for opening links in new tabs and pasting from the X buffer.
The libinput dev's response was a combination of incredulity that someone wouldn't have physical buttons (in like 2014) and a statement that the project would never add this feature. I haven't gone back to Wayland since.
That "dev" you're criticizing here has been developing libinput solo since the beginning. He asked for help numerous times and never received any. So either step up and do the work, or stop complaining.
libinput is yet another of those fundamental libraries that receive almost no developer attention, but get all the blame when something goes wrong: https://xkcd.com/2347/
He could also not have written libinput to begin with. libinput became the default because of political pressure from Red Hat and now we can’t complain if it’s worse than the project it is replacing?
There isn't any political pressure from Red Hat. They're often the only company that does any work on the input stack in userspace, without them it would probably not even exist or be stuck in a very old state. You can complain but it's unlikely to be of much use when the real issue is lack of manpower and there just aren't enough people to respond to all the complaints users have. A surefire way to solve that would be to start contributing, Red Hat won't stand in your way.
> libinput became the default because of political pressure from Red Hat
I don't know if this is true, but when comparing the KDE configuration screens for both, it sure seems like it must be true. libinput is missing much that synaptics has and doesn't seem to do anything better as far as I can tell. Unfortunately, just because a developer is working hard and pouring his heart and soul into something, doesn't mean the result is actually worthwhile.
It's not really true at all. The libinput developer blogged about why having more configuration options has historically not actually been good for the project, or for users of the synaptics driver:
Particularly, once you add a configuration option, you're now on the hook to support that option indefinitely as long as the project exists and users expect that option to be there. With more maintainers and testers, it may become feasible to have more configuration options, but it's still not a good idea to just keep piling them in. It might be satisfying to see a big configuration panel with a lot of settings but it's a lot less satisfying when you figure out a lot of the configuration options don't work correctly because the underlying system has bugs or is under-maintained or was just never tested with your specific configuration because input is hard and requires near constant testing against an extremely large number of hardware devices.
One-size-all doesn't fit me. synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned.
An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands.
As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists.
>synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned.
From a maintenance perspective it is unfortunately not that simple. I sympathize with your frustration and personally I too wish it was that simple but it is not. The synaptics driver might be able to do some things better but those things can also cause bugs to manifest in other areas, and have historically done so.
>An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands.
Well this is an open source project so you (or anyone else) can tell him if you really want. Have you checked if there is an open feature request on the tracker for this? Or better, can you propose a configuration API that would work well here, and can you help maintain it and test it on the hundreds of devices that it might potentially affect? I checked and I couldn't find any feature requests or proposals for this but maybe I missed something. If you don't want to do this then you may have to wait until somebody else makes the proposal and until the maintainer gets bandwidth to do that non-trivial amount of work, which is prioritized against all the other feature requests that might have been received.
>As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists.
But that's not the case at all. I'm sure you understand, there are a lot of other devices out there besides your particular touchpad and synaptics touchpads in general. You may want to read the rest of the libinput developer's blog about some of the motivations behind libinput, it solves very real problems that were directly caused by the synaptics driver. If you never encountered those bugs, that's great for you and you can continue to use it, but this was not how it was for a lot of other users. Remember we're still in this area where a critical project like this is only really being maintained by one developer, if they quit then you're left with no developers working on the input stack at all.
> "In libinput the edge scrolling is hard coded to 7mm and previous attempts at making it configurable were rejected."
I guess I should have quoted that full sentence. If somebody else does the work for him he'll still reject it. I've read the blog post you linked, he's most concerned about keeping the software simple, not making it actually work for real people. I think I have better things to do with my time than try to bring this guy around to my way of thinking. When I said "somebody should tell him" I was being facetious; that different people have different size fingers should have been obvious to him from the start, so he's clearly a lost cause.
> The synaptics driver might be able to do some things better but those things can also cause bugs to manifest in other areas, and have historically done so.
Well hypothetical or historical bugs don't concern me. Synaptics is working for me and always has. And I'm certainly not the only one.
> But that's not the case at all. I'm sure you understand, there are a lot of other devices out there besides your particular touchpad and synaptics touchpads in general.
It's a common misconception that the synaptics driver is only for synaptics touchpads. From the manpage:
> The name "synaptics" is historical and the driver still provides the synaptics protocol parsing code. Under Linux however, the hardware-specifics are handled by the kernel and this driver will work for any touchpad that has a working kernel driver.
Edit: I realize I probably sound unreasonably annoyed by software I don't even use, so let me explain: because of Red Hat, distros are now defaulting to libinput and I now have to work around this to continue using synaptics. It's caused me inconvenience despite me never wanting to use it in the first place. I earnestly wish it would just go away.
> he's most concerned about keeping the software simple, not making it actually work for real people.
You think your use case represents "real people"? Your problem is so niche it's not unreasonable for the developer to recommend you fork it and maintain your change as a fork for as long as you wish to use it. Real people don't fiddle with their touchpad settings to that extent. It's quite alright for you to prefer more complex solutions as well, but the vitriol towards libinput, a fantastic solution for 99.999% of users is undeserved.
This niche is not "real people" because "real people" don't use Linux. At the same time there are a lot of unreasonable requests, and the developer makes something free and shouldn't be bothered with such a low reward. Rudimentary functionality in Linux is quite good, maybe it will be a real issue in usage, but "real linux" users use keyboard. ;)
I just saw your edit and I'll respond to it separately. I don't understand what you mean by "because of Red Hat". Maybe Fedora and RHEL are shipping libinput but other distros don't have to do that, it's their decision to use it and not default to synaptics. You could probably find one that doesn't use libinput, or you could ask your distro not to use libinput by default, but you may have limited success with that because of the other issues with the synaptics driver that weren't really ever fixed. It's an unfortunate decision that distro developers have to make and it's solely their decision, not Red Hat's.
Although it's not really a coincidence if they make a lot of the same decisions that Red Hat does as they also have to field the same type of bug reports in these components and generally they will make similar decisions focused around minimizing bugs, sometimes at the expense of no longer getting to say that they support a giant feature matrix. I'm using debian for example and I don't think there are any other efforts or desire from downstream to focus on fixing the long standing issues in these old xf86 drivers for hardware that a lot of distro developers may not even have access to so they can test their changes. Wishing libinput to go away isn't really an effective problem solving strategy as that won't solve any of the issues with the old drivers that caused them to get removed as the default.
>If somebody else does the work for him he'll still reject it.
I would like to see this statement where he said he would reject it, I searched and couldn't find any statements to that effect. If it was rejected for some technical reasons then a way to proceed would be to address those reasons and then make a proposal from there.
>I think I have better things to do with my time than try to bring this guy around to my way of thinking. When I said "somebody should tell him" I was being facetious; that different people have different size fingers should have been obvious to him from the start, so he's clearly a lost cause.
I don't think you are operating in good faith here. It seems a bit ridiculous to suggest the person who maintained the very synaptics driver you're using doesn't know that finger sizes can vary. Again, if you want to change minds, the best way to do that would be to make a proposal that will actually work and offer to help shoulder the maintenance burden. That goes a lot farther towards convincing people toward your way of thinking than anything else, if you haven't done that I don't think you can honestly say you've made a complete effort. At least that is my view on how these things go when somebody says they're overwhelmed and they need help. This is pretty much exactly what happened with the recent touchpad changes, somebody else raised some money and offered to take up a lot of the work, and that's why we're commenting on this article :)
>Well hypothetical or historical bugs don't concern me. Synaptics is working for me and always has. And I'm certainly not the only one.
Sure, but for some others it hasn't worked, and for the maintainer the historical bugs always concern them. If you intend to work on this and contribute in a meaningful way, you can't ignore those. A good way to start contributing might actually be to go and look at some of those historical bugs so you don't cause a regression.
>It's a common misconception that the synaptics driver is only for synaptics touchpads.
I am aware of this, the scope of libinput is still much larger than the scope of that driver. That was what my point was.
> I would like to see this statement where he said he would reject it, I searched and couldn't find any statements to that effect.
It follows from his reasoning that allowing the user to configure the driver to their personal preference would make his job harder because it increases the number of possible configurations. And also from him rejecting such a proposal already.
Can you please share the email or issue where the proposal was made and where it was rejected? I still can't find it. I'd like to continue this conversation and discuss what can be done about it, but we can't discuss this much further without that because I don't really know what you're talking about. I will even look at the proposal and tell you what can be improved about it so maybe it can be made again in a better way. If the reason it was rejected is it because it made his job harder, a way to solve that would be to offer to contribute so you can make his job easier and take some of the maintenance load off him.
I exclusively use the trackpoint for mouse input and configuring the edge scroll to occupy the entire touchpad meaning that I can use my thumb to scroll without moving my hand away from the trackpoint.
In libinput the edge scrolling is hard coded to 7mm and previous attempts at making it configurable were rejected.
Some HP laptops (EliteBook 8xx) have a track point but only have two physical buttons.
They're also quite large and flimsy, so I expect them to develop enough play that reliably pressing both at the same time becomes frustrating after a while.
These specific ideas? To the best of my knowledge, no.
Other related ideas like Nix/NixOS/Guix are solving some of the same problems outlined in the article in a much more systematic way that are not reliant on any one file system.
And also, if I understand correctly, NixOS and Guix need much less help from developers than this proposal would have. Specifically, NixOS and Guix don't care how anyone names anything (except, of course, their dogs).
is anyone using these systems in production? I would immediately apply to work in such a place.
It's a catch-22. The biggest gain in using NixOS/Guix are production systems big enough where it matters. And every place that grows big enough where this would be good for the them they usually roll their own ... Because tech-debt doesn't allow them from switching to another OS + they have so much duct-tape that if they'd replace it, would also have to find work for those doing the duct-taping. I think it's not a technical problem at all, nor do I think it's because we lack ideas.
Yes, there are places that are using NixOS in production. I don't know the details, so this is a placeholder for someone else to fill in - or else ask on the NixOS subreddit or IRC channel.
Nix/Guix is a very simple and elegant design, but I find it has a downside: because every package is immutable, a security fix in a low-level shared library (worst case: glibc) requires recompiling every package that depends on it, and because there is no difference between OS and applications - everything is a Nix package - you have to wait until the whole dependency graph is recompiled before you can effectively install the security update.
TFA's design avoids this by separating out both a base OS layer and an application runtime layer, both of which have a bounded size.
Many users have a poor understanding of what Flakes _actually_ are: They are a bit of UX glue on top of existing Nix features:
- Input/output schemas for `flake.nix`
- A lock file format
- CLI features to work with the two above
It's entirely feasible to build out a Flake user interface & evaluation support on top of Tvix without making it a first-class evaluator feature. See https://github.com/edolstra/flake-compat for prior art.
The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.