Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS on Framework Laptop

kvark.github.io

Post reply on HN
Print view View original

221–230 of 250 posts

Re: NixOS on Framework Laptop

#221

Post by claytonjy »

k1rcher wrote: post #141
claytonjy wrote: post #111

Earlier quoted context omitted.

I'm seeing similar, maybe closer to 8 if it's mostly browsing and light IDE work, and I never run full brightness. I should probably chime in on the forum, but per that thread I tried Wayland but it didn't go so well, particularly with an external monitor plugged in. Too many misbehaving and misscaled apps, I remember having issues with vscode (scaling) and either kitty or alacrity (can't move or adjust window).

Interesting, that is very good to know. I have yet to try external monitors (will be plugged in tomorrow morning for work), but have been waiting on switching to Wayland to see if it’s necessary or not. Great to hear about the 8 hour duration as well, I’m absolutely loving this new toy!

I should point out Wayland isn't all-or-nothing; if you enable the config from that post, it's an option you can select when logging in. I never had to "go back" from Wayland, I just stopped selecting it, and can try it out again whenever.

Re: NixOS on Framework Laptop

#222

Post by burntsushi »

celrod wrote: post #112
cephalization wrote: post #55

Earlier quoted context omitted.

It definitely does not support 1 hand lid operation. Despite the quality not being as high as a macbook pro (I've owned several for comparison) it absolutely does not feel cheap. In cases where you may damage the device, part of the beauty is that all of the parts are sold by Framework and come with replacement guides and any tools you may need (usually just the included screwdriver).

From context, do you mean "It definitely does support 1 hand lid operation" instead of "It definitely does not"?

They must, because I open my Framework laptop with one hand all the time hah. Never had any problems with it.

Re: NixOS on Framework Laptop

#223

Post by mindslight »

5e92cb50239222b wrote: post #212
mindslight wrote: post #147

Earlier quoted context omitted.

I get the rationale. it just makes for one more layer of indirection that you have to overcome when trying to figure out what the configuration actually looks like.

Why would you do this manually? You also have to remember to check multiple configuration paths (e.g. override units), all of which can have an additional `.d` include directory. This is the price you pay for the flexibility systemd provides (and I argue it's much better than random System V-style shell scripts that can include anything at all, maybe even some remote scripts piped from curl to sh if developers was ma…

Does `systemctl cat` also work for creating/editing units? If I've got to navigate files and directories configure the thing, then I am going to default to reading the configuration the same way. Having to find out these random commands to view simple things about its own internal model is one of the the worst parts of systemd.

I'm no fan of SysV init either, and I appreciate the advancements that systemd does bring to the table. But it is hard to shake the feeling of it having done the system software equivalent of sucking in a bunch of bloated javascript frameworks. Sure they made life easier for the developer, but everyone else has to live with the mess.

For enabling/sequencing, I'd say the preferable way would be to have a top level config file that pulls in the specified units explicitly rather than stitching together units based on their internal contents (akin to persistent structure rather than mutable cells). Juxtaposition is the most syntactically powerful operator and prevents loops intrinsically. Whereas by splaying dependencies in unit files, if you make one errant backreference the system is likely to not boot at all. I'm sure there's another clever command to check for that, but shrug.

Re: NixOS on Framework Laptop

#224

Post by josephcsible »

viraptor wrote: post #73
Yuioup wrote: post #24

I take it the big vendors (HP, Dell, etc) are now going to start adopting Framework's business model? If not the obviously somebody's gonna try and buy them for billions.

Why would they? Most people will still buy a generic laptop. Fairphone released version 4 already and it's not like Samsung, Apple, Motorola, and others got even close to that level of repairability.

Fairphone isn't even for sale in America.

Re: NixOS on Framework Laptop

#225

Post by md8z »

CameronNemo wrote: post #180
md8z wrote: post #159

Earlier quoted context omitted.

Well you have to understand that my mental picture from your past description is FreeBSD running in KVM on NixOS running on managed GCP/AWS, which is a somewhat confusing and convoluted architecture to me and I'm not sure what it's for or what the possibilities are that can't be done with some other setup. You could probably simplify and cut out some of those pieces. But if you meant something else, then let me know.…

>it is racy to have more than one process writing to the toplevel hierarchy Source? And define top level hierarchy? The top level isn't really special. This is why locks exist btw. I'm not convinced you have to manage cgroups from one process. That is not how most implementations do it. >Processes cannot just freely break out of their cgroup, that wouldn't be secure. Processes can freely migrate ("break out" if you i…

I'm sorry I don't understand what you're asking for specifically, the source is the cgroups API. Check the documentation I posted earlier, particularly this line:

"Because the resource control interface files in a given directory control the distribution of the parent’s resources, the delegatee shouldn’t be allowed to write to them."

You could add locking but that would be basically doing what systemd/docker/runc does and adding a new API on top of it which is then available through D-Bus or whatever. The top-level hierarchy is the top of any cgroup tree, if you have two processes writing to that without synchronization then they will potentially stomp over each other's values. You technically can go and run "sudo mkdir" inside your docker's toplevel cgroup but that would probably break things.

"if they have write access to one level above them in the tree. Systemd does not put you in that situation, but it could."

Well it does do that if you turn on delegation by giving you your own sub-tree, it doesn't do it by default because most services are not container managers and don't need an additional sub-tree. If you don't do that then write access is not allowed by the cgroups API, see above. It would not really make sense to allow a child process to say "I am going to take 100% of the cpu controller now and you get none sorry", that would defeat the purpose of cgroups.

Re: NixOS on Framework Laptop

#226

Post by soraminazuki »

ayushnix wrote: post #170
ptaken wrote: post #10

Earlier quoted context omitted.

Nix + home-manager is how I started on arch. After moving about 80% of my Pacman-installed packages over to nix-configured packages bit by bit over weeks and after that all of my dotfiles I plunged into nixos. Transition was super smooth, can only recommend!

Can I install packages not present in the official NixOS repositories without learning the Nix DSL?

You can, if your repository of choice provides a Nix channel[1]. However, the community effort is currently concentrated in the official Nixpkgs repository. So while there are numerous projects based on Nix run outside of the NixOS organization, there aren't any "major" unofficial package repository that I'm aware of. For packaging work, people just tend to contribute directly to the official repository. In fact, the volume of PRs in the official repository is so high I'm surprised at how they manage to keep going in spite of that.

It's also worth noting that many of the benefits of Nix are directly driven from being able to write custom Nix expressions. So if you want to reap all of its benefits, it's definitely worth learning. The core language is small and the experience is not so far off from writing JSON, so that part is relatively easy to pick up. The actual work lies in learning how packaging is done in Nixpkgs. This is best done by grepping around the Nixpkgs repository for examples. Nixpkgs' policy of having all packages in a single repository really shines here.

[1]: https://nixos.wiki/wiki/Nix_channels

Re: NixOS on Framework Laptop

#227

Post by spamizbad »

jonfw wrote: post #217
_4fwd wrote: post #47

Earlier quoted context omitted.

What's the secret on battery life?

The archwiki has a ton of interesting content on optimizing battery life on linux- https://wiki.archlinux.org/title/TLP https://wiki.archlinux.org/title/Laptop https://wiki.archlinux.org/title/Power_management Even if you're not running arch, the archwiki is an amazing source of information

Yep, those are the guides I loosely followed.

Re: NixOS on Framework Laptop

#228

Post by soraminazuki »

ben0x539 wrote: post #98
claytonjy wrote: post #3

As a framework owner, this is nice to see. I have yet to take the plunge on Nix (been happy with PopOS on mine), and wouldn't without Bluetooth support, but it's good to know it's possible and relatively painless. I'm hoping to start with nix+home-manager at some point, maybe on top of PopOS; anyone have experience with that setup?

Somewhat random question: What kind of run time do you get out of a battery charge with PopOS on the framework laptop? I've seen some comments from people who were unhappy with theirs, but maybe PopOS has some better tuning?

My understanding is that the options for tuning battery life on Linux are pretty much the same across Linux distros. You either have TLP, Laptop Mode Tools, Powertop, or Gnome Power Manager, all of which tunes kernel settings in a similar fashion. Thermald might possibly help too, but I'm not sure if it has positive effects on battery life.

The only factor that I could think of that might make a difference across distros is the availability of hardware video acceleration in browsers. But that gap is likely to close soon, if there are any right now.

Re: NixOS on Framework Laptop

#229

Post by CameronNemo »

md8z wrote: post #225
CameronNemo wrote: post #180

Earlier quoted context omitted.

>it is racy to have more than one process writing to the toplevel hierarchy Source? And define top level hierarchy? The top level isn't really special. This is why locks exist btw. I'm not convinced you have to manage cgroups from one process. That is not how most implementations do it. >Processes cannot just freely break out of their cgroup, that wouldn't be secure. Processes can freely migrate ("break out" if you i…

I'm sorry I don't understand what you're asking for specifically, the source is the cgroups API. Check the documentation I posted earlier, particularly this line: "Because the resource control interface files in a given directory control the distribution of the parent’s resources, the delegatee shouldn’t be allowed to write to them." You could add locking but that would be basically doing what systemd/docker/runc doe…

What have you worked on in this space?

Re: NixOS on Framework Laptop

#230

Post by mbakke »

phaer wrote: post #191
globular-toast wrote: post #185

Earlier quoted context omitted.

Replace NixOS with Guix and I agree!

I'd love to see Guix with SystemD, but there's no work going in that direction that I am aware of. While I appreciate the work on [GNU Shepherd]( https://www.gnu.org/software/shepherd/manual/shepherd.html ), especially their documentation quality and the use of scheme instead of the rather obscure nix language, learning yet another init system on top of a new distro while systemd seemingly has won most of the market…

Even if Guix were to switch to systemd (it won't), end users would primarily be interacting with services through the same high-level APIs as now.

https://guix.gnu.org/manual/devel/en/guix.html#Services

That is, the only difference in practice would be replacing 'herd' with 'systemctl' when stopping and starting services manually. Anything else, such as modifying a service, has to go through the configuration system.

Similarly, for service authors, whether the API you design ends up creating a systemd unit file or shepherd service object is an implementation detail and would be mostly transparent.

Post reply on HN