wasted_intel

That comparison is made on the project homepage:

"Not a security mechanism. No mount isolation, no PID namespace, no credential separation. Linux documents it as not intended for sandboxing."

First thing I thought of, too. If not, I hope it’s planned. I’m all in on TUI tools, and vi keybinds are a necessary part of that for me.

Validity | https://www.validity.com/ | Boston - Remote (US) | Full-time

Validity is a suite of marketing tools used to ensure data quality, drive email performance, and provide advanced campaign analytics to leading brands.

Our Applications team is seeking a Senior Ruby on Rails developer to help expand our product line, improve our existing products, and build the next generation of Validity tools, continuing our mission to provide exceptional support to our growing customer base.

We're looking for someone with: - A strong command of Ruby, Ruby on Rails, JavaScript, and the architecture of large web applications at scale - Experience in taking projects from concept to completion - Strong communication skills; the ability to communicate clearly, effectively, and with empathy both within your team and cross-functionally - A proven track record of writing clean, maintainable, and well-tested code

Apply here: https://validity.applytojob.com/apply/9cSl8hGG4R/Sr-Software...

Love this. I use raw CLI commands until it hurts, and have recently embraced tools like lazygit/lazydocker to get visibility into otherwise opaque system/tree states, and it’s been a huge level-up.

I have several user and system level services I manage, but debugging them is tedious. Your opening line that lists common commands and their pain points really resonated with me.

I’m on NixOS, so editing immutable unit files directly won’t work, but the service discovery, visibility, and management will be really helpful. Nice work!

Your comment about writing a text editor library is precisely what got me started with amp ~10 years ago, where much of its core functionality was extracted here:

https://crates.io/crates/scribe

Good luck with the project! Building a text editor to scratch your own itch is fun.

I also think NixOS is more targeted towards developers. It’s one thing to learn the syntax, APIs, and abstractions of Nix/NixOS. It’s another to stack all of that on top of learning programming in general.

This doesn't mirror my experience at all. I think the biggest challenge facing NixOS is the learning curve. There's a lot thrown at you from the start, and as you start to factor your configuration into separate modules, there's a lot of complexity you have to unpack.

I've since migrated to a flake-based setup with machine-based variations (for my laptop and desktop), including easily swappable desktop environments. At a whim, I can switch between sway, hyprland, and gnome. This was mostly a result of me exploring/tweaking these without wanting to discard the configs; I always end up coming back to re-explore tiling WMs.

My experience through all of this has been great. I've even done a full re-install on both machines when the xz vulnerability was discovered and the process was effortless. That includes lanzaboote for SecureBoot, LUKS, and out-of-tree git-based flake builds for custom applications I build from source.

The one thing I found really helpful when starting with flakes was this repo that includes starter configs to help flatten that initial curve: https://github.com/Misterio77/nix-starter-configs/tree/main

Oh, Arch was rock solid and I was also able to keep my install going for years. However, in the few instances where I would get a new laptop or experience a drive failure, it was non-trivial to get it going again. If you're using a stock install + Gnome, it's not bad, but I had lots of things set up (e.g. Secure Boot, udev rules, usbguard, tiling WM, etc.) and those are all things you can declare in a NixOS + Home Manager config, have versioned, and re-establish in ~30 minutes instead of days.

Yep, same. Thoroughly enjoyed Arch, but slowly accruing implicit config state means you'll eventually have to re-install and configure everything again. You can mitigate some of that with dotfiles and some hand-rolled scripts, but NixOS is effectively that "done right".

I get the point you're making, but I'd argue that even when stated in a reductive fashion, the complex system that leads simple cellular automata to artistic expression is orders of magnitude more elegant and special than AI.

Exercising “rights and freedoms” isn’t what the people in that protest were doing. Breaking that up was the right thing to do.

> which are OSS-compliant where required

This is the crux of the problem. Where Prusa is openly sharing, you have companies that are benefiting from that without reciprocating. Part of the tax you're paying when buying an i3MK4 is the continued investment in the open source/hardware contributions of the company, not just the end product. Shelling out $1k for a Bambu is your prerogative, but it does cast a vote with your wallet for a company that is more predatory than collaborative.

Litmus | Remote (USA, UK) | Full-time | https://litmus.engineering

Litmus' goal is to help email marketing teams send better email. To do that, we've built a suite of tools to help with the building process, allow performing QA with device/client screenshots, enable collaboration on designs with teammates, and analyze email performance post-send.

We're looking to hire a full-stack engineer to help add/improve features and build new products. Day to day, you can expect to write Ruby and JavaScript (Rails, vanilla JS, Vue.js, Ember, etc.). We practice CI/CD with great test coverage, are sincerely good about work/life balance, and have some exceptional benefits (e.g. 28 days of PTO + stat holidays). You can learn more about our team and how we work here:

https://litmus.engineering/applications-team

If you'd like to apply, you can see all of our open engineering positions here:

https://litmus.engineering/careers

Litmus | Remote (USA, UK) | Full time | https://litmus.com

Litmus' goal is to help email marketing teams send better email. To do that, we've built a suite of tools to help with the building process, allow performing QA with device/client screenshots, enable collaboration on designs with teammates, and analyze email performance post-send.

We're looking to hire two Rails developers to help add/improve features and build new products. Day to day, you can expect to write Ruby and JavaScript (vanilla, Vue.js, Ember). We practice CI/CD with great test coverage, are sincerely good about work/life balance, and have some exceptional benefits (e.g. 28 days of PTO + stat holidays).

Please see the listing for all of the details:

https://grnh.se/3445d0254us

> it is not easy for people who just can't be bothered to take the time to make anything correctly

Laziness may make the problem more likely, but even a disciplined team working on security-critical software can make mistakes[0].

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777

Litmus | https://litmus.com | Boston | Full-Time | REMOTE

Litmus is building a platform to help email marketers, agencies, and companies send better email. We write and maintain tools that cater to the email design process, like creating the HTML/CSS, collaborating with others on the design, verifying accuracy with email client screenshots, and analyzing campaign performance.

We're hiring a Rails developer (we do have Vue and Ember in use, too). You'd work alongside a team of smart, curious, and supportive people working on challenging problems. Apply here before April 6th:

http://jobs.litmus.com/apply/6xEByC7zhC/Ruby-On-Rails-Develo...

I had the same experience with the Globe and Mail in Canada. You get ads regardless of whether or not you're a paying subscriber, and while you can sign up online, you can't cancel. It was a total pain in the ass to do that over the phone, and it's a glaringly-obvious (and misguided) retention tactic.

I'll never subscribe to them again. What a short-sighted way to optimize for revenue at any cost.

Thanks for the head's up; much appreciated!

> If you use it on multiple windows, doing `scratchpad show` multiple times causes one window to appear, then disappear, then next window appear, then disappear... and it does this across workspaces.

You need to create a keybinding that calls `scratchpad show` using a window class qualifier to target the app you want. That's the key to making the scratchpad useful.

Try nmcli to get rid of your nm-applet dependency. ;)

I'd love to switch, but we use Zoom at work and screen sharing in Wayland was unsupported, last I checked.

i3's "scratchpad" alone is worth switching. You can show/hide a floating window on any workspace with a single hotkey. I use Chrome's app mode to launch dedicated windows for frequently used sites (Calendar, Slack, DevDocs) and I can call them up easily. Works wonderfully for native apps, too, like Spotify.

I tried Gnome recently, and although it's very polished, I switched back to i3 because it wasn't nearly as intuitive to drive with the keyboard.

Funny, I have an XPS13 (9370) and I love the aesthetic; the carbon fiber and metal look/feel is really nice. It's light, works well, and is quiet. The keyboard leaving imprints on the display is no different from my 2013 MBP, whose design everyone still seems to love.

While I agree that knowledge of what's below those abstractions is important, you also need to cater to your audience. Getting something working on the screen in front of you is exciting for new folks; lining up little victories with increasing complexity feels like a path that would be more enjoyable to follow. As long as the person maintains a curiosity about the underlying technology, they can work down into the lower layers as their interest dictates.

Well said. I switched to an XPS-based Arch build for many of these reasons.

I think computers are generally too complicated for lay users. People tolerated the quirks because there was no alternative. Even on a Mac, which wouldn't suffer from the same hardware compatibility issues as a PC/Windows machine, users would still need to understand how to organize files, properly close applications, and avoid running/opening arbitrary programs/files from the internet. And that's if they could connect to the internet at all.

iOS and its ilk solved all of that. And in that moment, the number of people who needed to be exposed to all of that underlying complexity shrank considerably. There is most certainly something lost for those people, but at the end of the day, there is a cognitive cost to understanding how those pieces work, and I think the mass market has shifted away from implementations that require (or allow for) that visibility. I think that's fine, provided there are still hardware options available to the rest of us. :)

For vanilla references (&), Rust will prevent you from having multiple mutable references. Beyond that, there are several types in the stdlib[0] that progressively increase flexibility, but always safely.

I think it's bad advice because you need to know what is potentially dangerous. That alienates newcomers to systems programming (which is why one of Rust's goals is to be able to "hack without fear"). There are also some designs that I'd never try to build without safety checks, because they're notoriously hard to get right. Even knowing the fundamentals of memory safety, without a way of enforcing lifetimes and mutability, writing zero-allocation implementations that share immutably can be daunting.

[0] Cell, RefCell, Mutex, Rc, Arc

Rust 2018's non-lexical lifetimes are a good example of this.

> well, try to avoid doing that

I think that's pretty terrible advice for something that affects memory safety, and it invalidates your entire "the compiler will warn you" argument. There's a reason Rust has ownership and lifetime annotations: there are many things that a compiler simply cannot infer.